Bug 757732 - Provide a way to use versions to resolve artifacts
Summary: Provide a way to use versions to resolve artifacts
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: maven
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Stanislav Ochotnicky
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-11-28 14:34 UTC by Stanislav Ochotnicky
Modified: 2012-01-31 15:21 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-01-31 15:21:39 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.