Bug 757732

Summary: Provide a way to use versions to resolve artifacts
Product: [Fedora] Fedora Reporter: Stanislav Ochotnicky <sochotni>
Component: mavenAssignee: Stanislav Ochotnicky <sochotni>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: akurtako, cdewolf, java-sig-commits, sochotni
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-01-31 15:21:39 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Stanislav Ochotnicky 2011-11-28 14:34:54 UTC 
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
Comment 1 Alexander Kurtakov 2011-11-28 14:51:56 UTC 
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.
Comment 2 Stanislav Ochotnicky 2012-01-31 15:21:39 UTC 
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.