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(a)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(a)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.
--
Configure bugmail:
https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.