This may not be related, but if whatever web server ivy is pulling from
does not generate directory listings (that ivy can parse) then ivy can't
discover what revisions exist, so it then can't resolve revision ranges.

-Archie

On Tuesday, June 2, 2015, Geißler, Daniel <daniel.geiss...@salt-solutions.de>
wrote:

> Hello,
>
> I am using ivy 2.4.0 and having strange results on ivy resolves.
>
> From time to time some of my projects don't resolve the configured dynamic
> revisions correctly. At the end of the resolve process ivy prints out
> numerous evicted revisions and the latest-revision strategy selects no
> revision. This leads to build failtures as you may guess as the classpath
> is incomplete.
>
> Now in the past some random shifting of the dependency lines in the
> ivy.xml did fix that but I really like to know what happens here and how I
> can fix that once and for all.
>
> So this is an example of the output for the evicted revisions:
>
> [ivy:resolve] :: resolution report :: resolve 20428ms :: artifacts dl
> 1259ms
> [ivy:resolve]       :: evicted modules:
> The first two libraries are common 3rd party libraries which may change in
> the minor versions. They are just transitive dependencies of other
> artifacts that address them by: rev="5.0.+"
> [ivy:resolve]       com.mycompany.platform#logging;5.0.2 by []
> ([latest-revision]) in [compile]
> [ivy:resolve]       com.mycompany.platform#util;5.0.2 by []
> ([latest-revision]) in [compile]
> Others are direct dependencies that are in the projects ivy.xml:
> <dependency org="com.mycompany.product" name="Checkpoint" rev="16.1.0.+"
> conf="compile-&gt;default"/>
> <dependency org="com.mycompany.product" name="WorkcenterCalendar"
> rev="16.1.0.+" conf="compile-&gt;default"/>
>
> The related output of the evicted section is:
> [ivy:resolve]       com.mycompany.product#Checkpoint;16.1.0.0-SNAPSHOT by
> [com.mycompany.product#Checkpoint;16.1.0.+] in [compile]
> [ivy:resolve]
>  com.mycompany.product#WorkcenterCalendar;16.1.0.0-SNAPSHOT by
> [com.mycompany.product#WorkcenterCalendar;16.1.0.+] in [compile]
> [ivy:resolve]       com.mycompany.product#Checkpoint;16.1.0.+ by []
> ([latest-revision]) in [compile]
> [ivy:resolve]       com.mycompany.product#WorkcenterCalendar;16.1.0.+ by
> [] ([latest-revision]) in [compile]
>
> So if i read this correctly ivy decides to replace the (correctly)
> resolved revision 16.1.0.0-SNAPSHOT with the dynamic revision 16.1.0.+ and
> after doing that it replaces this revision with nothing ??
> There are numerous other dependencies declared exactly the same way that
> do not show this behavior but resolve correctly to their SNAPSHOT revision.
>
> I have configured the resolvers in ivysettings.xml like this (chain
> resolvers get the same attributes as well):
>
> <macrodef name="resolve">
>
>         <attribute name="repository" />
>
>         <ibiblio name="@{name}" m2compatible="true" latest="my-strategy"
> root="${ivy.repository.root}/@{repository}"
>
>             checkmodified="true" changingMatcher="regexp"
> changingPattern=".*-SNAPSHOT.*" />
>
>     </macrodef>
> The special strategy is just to give some versions a explicit ordering:
>
> <latest-strategies>
>
>         <!-- special sorting for version number -->
>
>         <latest-revision name="my-strategy"
> usedefaultspecialmeanings="false">
>
>             <specialMeaning name="Final" value="5" />
>
>             <!-- general availability -->
>
>             <specialMeaning name="GA" value="4" />
>
>             <!-- developement version -->
>
>             <specialMeaning name="SNAPSHOT" value="3" />
>
>             <!-- release candidate -->
>
>             <specialMeaning name="RC" value="2" />
>
>             <!-- beta version -->
>
>             <specialMeaning name="Beta" value="1" />
>
>             <!-- alpha version -->
>
>             <specialMeaning name="Alpha" value="0" />
>
>         </latest-revision>
>
>     </latest-strategies>
>
> I used to see this effect with ivy-2.3.0 and without a special
> latest-strategy too.
>
> Anyone has ideas why this is happening and how to fix that?
>
> Any help is apreciated!
> Daniel
> _____________________________________
>
> www.salt-solutions.de<http://www.salt-solutions.de>
>
> Geschäftsführer: Dr. Bernhard Blüthner, Dieter Heyde, Markus Honold
> Sitz: München, AG München, HRB 146081
>


-- 
Archie L. Cobbs

Reply via email to