-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 21/06/14 03:26, Peter MacKinnon wrote:

After updating to jline-2.10-14.fc21.noarch, I found this:

$ repoquery -f 'mvn(jline:jline)' jline-0:2.10-14.fc21.noarch $ repoquery -f 'mvn(jline:jline:1)' jline1-0:1.0-7.fc21.noarch $ repoquery -f 'mvn(jline:jline:1.0)' jline1-0:1.0-7.fc21.noarch $ xmvn-resolve jline:jline:1.0 /usr/share/java/jline/jline.jar $ xmvn-resolve jline:jline:1 /usr/share/java/jline/jline.jar $ rpm -qf /usr/share/java/jline/jline.jar jline-2.10-14.fc21.noarch

$ rpm -q ivy-local ivy-local-4.0.0-8.fc21.noarch

The difference from the previous version of jline (-13) is this provides decl: mvn(jline:jline:pom:) = 2.10

Hi Peter,

This is intentional new behaviour. mizdebsk explained it best to me on IRC:

Jun 10 19:46:14 <grdryn> I'm getting broken dependency mails about it since mass rebuild. I also have to change it to truecommons-parent in local mock, even after explicitly installing truecommons-parent (and checking that it Provides mvn(net.java.truecommons:truecommons-parent) ) Jun 10 19:55:29 <mizdebsk> grdryn, you can use mvn(net.java.truecommons:truecommons-parent:pom:) Jun 10 19:56:01 <grdryn> mizdebsk: thanks. Why is the extra : necessary now? Jun 10 19:58:06 <mizdebsk> xmvn used to support only jars, now it can handle any arbitrary artifact types Jun 10 19:58:28 <mizdebsk> old style provides: mvn(groupId:artifactId) Jun 10 19:58:54 <mizdebsk> new style: mvn(groupId:artifactId[[:extension[:classifier]]:version]) Jun 10 19:59:54 <mizdebsk> thus the trailing :pom: is required to distinguish between pom and jar Jun 10 20:00:04 <mizdebsk> grdryn, does it make sense? Jun 10 20:00:10 <grdryn> ah ok, got it, thanks Jun 10 20:00:18 <grdryn> yeah, I think it makes sense Jun 10 20:05:17 <grdryn> I'm guessing that the extra : is needed after extension to make it easier to parse that it's not the version, right? Jun 10 21:18:47 <mizdebsk> grdryn, yes Jun 10 21:20:35 <mizdebsk> possible variants are: Jun 10 21:20:41 <mizdebsk> mvn(groupId:artifactId) Jun 10 21:20:41 <mizdebsk> mvn(groupId:artifactId:version) Jun 10 21:20:42 <mizdebsk> mvn(groupId:artifactId:extension:version) Jun 10 21:20:42 <mizdebsk> mvn(groupId:artifactId:extension:classifier:version) Jun 10 21:22:19 <mizdebsk> this follows upstream scheme: http://download.eclipse.org/aether/aether-core/0.9.0.M2/apidocs/org/eclipse/...

Jun 10 21:22:46 <mizdebsk> with one addition: xmvn allows version to be omitted

I hope this helps! Apologies if I've misunderstood, and your query is subtly different. Hopefully pasting this here will help others and save Mikolaj some time from having to explain it to a few others at least :)

Gerard.

On 06/21/2014 04:26 AM, Peter MacKinnon wrote:

After updating to jline-2.10-14.fc21.noarch, I found this:

$ repoquery -f 'mvn(jline:jline)' jline-0:2.10-14.fc21.noarch $ repoquery -f 'mvn(jline:jline:1)' jline1-0:1.0-7.fc21.noarch $ repoquery -f 'mvn(jline:jline:1.0)' jline1-0:1.0-7.fc21.noarch

This all seems to be correct. I assume you showed it only for reference.

$ xmvn-resolve jline:jline:1.0 /usr/share/java/jline/jline.jar $ xmvn-resolve jline:jline:1 /usr/share/java/jline/jline.jar $ rpm -qf /usr/share/java/jline/jline.jar jline-2.10-14.fc21.noarch

jline uses new metadata while jline1 still uses legacy depmaps because it failed to build during mass rebuild (rhbz#1106951). Depmaps are used as a fallback - only if resolution using metadata fails. That's the reason jline "wins".

The solution is to fix rhbz#1106951, i.e rebuild jline1 so that it uses new metadada format.