Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=757732
Stanislav Ochotnicky sochotni@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |RAWHIDE Last Closed| |2012-01-31 10:21:39
--- Comment #2 from Stanislav Ochotnicky sochotni@redhat.com 2012-01-31 10:21:39 EST --- 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.