Currently our resolver ignores versions completely and returns unversioned jar all the time. The change should make it possible to differentiate. So when package A requests gid:aid:version but we don't have that same exact version installed it will return unversioned jar as before. If however, package B_v2 provides gid:aid:version requested by package A our resolver should prefer jar from this rpm to default unversioned one. This feature will probably require change to %add_maven_depmap macro as well
Hmm, if this is implemented the provides generator should really be changed to add the versions to the provide otherwise we will get 2 packages providing the same without anyway for rpm/yum to choose between them.
OK, so I implemented a simple version of this in 3.0.4-1: Let's say package asks for this: <dependency> <groupId>commons-collections</groupId> <artifactId>commons-collections</artifactId> <version>3.2.1</version> </dependency> We normally look into depmap in /usr/share/maven-fragments which contains: <dependency> <maven> <groupId>commons-collections</groupId> <artifactId>commons-collections</artifactId> <version>2.2.1</version> </maven> <jpp> <groupId>JPP</groupId> <artifactId>commons-collections</artifactId> <version>2.2.1</version> </jpp> </dependency> Because of this we used look for pom files (ignoring versions) /usr/share/maven-poms/JPP-commons-collections.pom and jar file /usr/share/java/commons-collections.jar New maven first looks for: /usr/share/maven-poms/JPP-commons-collections-3.2.1.pom and /usr/share/java/commons-collections-3.2.1.jar And only falls back to unversioned jars/poms if exact version is not found. This means it's possible to package rpm with alternative version by simply naming jar/pom name in the same way + the version. Advantage of this is that it doesn't require any big changes and it is fast. It might be a good idea to have a guidelines update that would describe how to package such alternative rpms.