----- Original Message -----
From: "Gerard Ryan" <galileo(a)fedoraproject.org>
To: java-devel(a)lists.fedoraproject.org
Sent: Saturday, June 21, 2014 10:53:59 AM
Subject: Re: [fedora-java] xmvn/jp-tools bug?
-----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
It seems like XMvn doesn't work correctly if compat package still uses old fragment
files instead of new metadata. This can be easily workarounded by rebuilding jline1, IMO.
I'm on it.
Michal
$ 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/eclip...
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iQIcBAEBCAAGBQJTpUgnAAoJEG7cfkpivEoVR2IP/ifmgq6Evu5dDq4APpocAFa4
U05Pn49cybWUB6xrgaE0fY8YzgNwr3mWgdFiQBmAKRaJwVmNHk/9MonXKGSOgOBL
rq3A3lErIn/2cbnjyL0rLfMNsDgx6gUPdhDtRVWCvp2m8vLY+vjqKHtpOHb8/Wm8
Szcp2hdb7TCbiF1sVmdMM+O1JzHkkajs5l50CJGCn3j2jDKpsgVAMn2BzBCz/Pnk
YRNPTDbOCd+avht+HbixlKf8aBN/4V0h5Kt7UA/0VLZRYSlJ0gQgwdpPHqXFN2cU
6oXXJofHemt9K9j33XBLLthKo8/rV0oBEFQbqAy9EyoSw/RHFa5RnexLhtrkgPE4
2Q/k87nooCdtmUAP0V8X8fltaBgKLynSUgxUM3fTwQMkuwHLzoXyFkcW0UG6AFmb
Ea+f8oAy9NXQkUx19DAvOPU0esIepBjoQTbqausy8GgeslfUAXn0bslDH/heKXhR
4PQMdzUN8R7c5nEtjLWWnl9ebPgIwi8A2u0aPfuRdF0qwG/ROtdQ5K2JjA0PeYun
8nIo3i0XlUcj9btJwvUQiLw7BwqD3VjYfs0wZK86MDJebbrSxKOlJKQS52MCqGcT
IbXZYfWDA17uIle3n+61bhFTAAjIfXeHNWoFQ51Tj5Kz7xhIrSnezxrU4WE4WjTV
FateSDTDoK6eYlOu014s
=nH48
-----END PGP SIGNATURE-----
--
java-devel mailing list
java-devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel