Yoav Landman-3 wrote:
>
> We tested programatically resolving the correct list of versions (assuming
> that when this work the Ivy client will take care of the rest). We used
> the
> URL resolver in m2-compatible mode and default Ivy settings. We tried both
> virtual repo URLs and local repo URLs as the repo root.
> We already tested both 2.0.7 and 2.0.8 with the same test case and it
> worked
> fine.
>
OK, very good. Then I should be able to achieve the same results with my
current installation.
Yoav Landman-3 wrote:
>
> Actually, the ibiblio resolver uses the maven-metadata.xml by default to
> get
> the list of versions, which can be seen as a more restful way.
>
I see. That is a nicer way to get the aggregated metadata than scraping the
html, but it seems that maven-metadata.xml must be generated externally to
Artifactory and uploaded. Am I wrong? Will it be synthesized on the fly if
it is requested?
Yoav Landman-3 wrote:
>
> Since getting the list of versions worked fine in all our tests, we
> assumed
> that once Ivy is getting back a correct list of versions from the
> repository
> something else goes wrong, so we also ran a full standalone Ivy test, with
> the following settings:
>
> <ivysettings>
> <settings defaultResolver="url"/>
> <resolvers>
> <url name="url" m2compatible="true">
> <artifact
> pattern="${test.repoRoot}/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]"
> />
> </url>
> </resolvers>
> </ivysettings>
>
> We used test.repoRoot = http://server:8081/artifactory/repo
>
> And ran something like:
> java -jar ivy.jar -settings <the-above-ivysettings-file> -dependency mysql
> connector-java [5.1.0,5.2.0]
>
> And that also worked as expected, resolving the correct artifact version.
>
> Do you have a particular version pattern that fails for you that we can
> try
> out?
>
I will try out your test-mechanism to figure out where I am breaking. The
patterns that I am having trouble with mostly seem to have +'s in them, and
exclusive range end values. Like:
:: commons-collections#commons-collections;3.2.1+: not found
:: commons-collections#commons-collections;3.2.+: not found
:: commons-logging#commons-logging;1.1.+: not found
:: commons-logging#commons-logging;1.+: not found
:: commons-collections#commons-collections;[2.+,3.2.+): not found
:: commons-logging#commons-logging;[1.1,2.0): not found
When commons-collections has versions 2.1.1 and 3.2.1 in the repo, and
commons-logging has v. 1.1.1, which should match all the above patterns. I
think. They do, at least, when I resolve with a filesystem resolver:
[3.2.1] commons-collections#commons-collections;[2.+,3.2.+)
[1.1.1] commons-logging#commons-logging;[1.1,2.0)
thanks,
--carl
--
View this message in context:
http://www.nabble.com/Ivy-resolving-wildcard-revisions-w--Artifactory-tp25394756p25461826.html
Sent from the Artifactory-Users mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Artifactory-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
