Description of problem: maven fails to resolve versioned artifacts if dependency version doesn't match exactly version specified in JPP depmap, even if the artifact file suffix matches version of the dependency. Version-Release number of selected component (if applicable): maven-3.0.4-14.fc19.noarch How reproducible: Pseudo-randomly (depends on depmap order) Steps to Reproduce: mvn-rpmbuild example:example:1.0:foo pom.xml contains: > <dependency> > <groupId>example</groupId> > <artifactId>example</artifactId> > <version>1.0</version> > </dependency> depmap.xml contains: > <dependency> > <maven> > <groupId>example</groupId> > <artifactId>example</artifactId> > <version>1.0-Final</version> > </maven> > <jpp> > <groupId>JPP/example1</groupId> > <artifactId>example</artifactId> > <version>1.0-Final</version> > </jpp> > </dependency> > <dependency> > <maven> > <groupId>example</groupId> > <artifactId>example</artifactId> > <version>2.0-Final</version> > </maven> > <jpp> > <groupId>JPP/example</groupId> > <artifactId>example</artifactId> > <version>2.0-Final</version> > </jpp> > </dependency> File system contains: > /usr/share/java/example1/example-1.0.jar > /usr/share/java/example/example.jar Actual results: maven resolves either of 2 jars (depeding on semi-random factors). In the above case /usr/share/java/example/example.jar is resolved. Expected results: maven resolves /usr/share/java/example1/example-1.0.jar Additional info:
I believe that this bug is fixed in maven-3.0.4-28, which is available in Fedora Rawhide. I am closing the bug now, thank you for reporting it. A summary of changes is included below. * Wed Jan 23 2013 Mikolaj Izdebski <mizdebsk> - 3.0.4-28 - Move mvn-local and mvn-rpmbuild out of %_bindir