Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
Summary: Provide a way to use versions to resolve artifacts
https://bugzilla.redhat.com/show_bug.cgi?id=757732
Summary: Provide a way to use versions to resolve artifacts Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: unspecified Priority: unspecified Component: maven AssignedTo: sochotni@redhat.com ReportedBy: sochotni@redhat.com QAContact: extras-qa@fedoraproject.org CC: akurtako@redhat.com, sochotni@redhat.com, java-sig-commits@lists.fedoraproject.org Classification: Fedora Story Points: --- Type: ---
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
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|NEW |ASSIGNED
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
--- Comment #1 from Alexander Kurtakov akurtako@redhat.com 2011-11-28 09:51:56 EST --- 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.
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.
java-sig-commits@lists.fedoraproject.org