On 1/15/07, Cecile <[EMAIL PROTECTED]> wrote:
Xavier, 2007/1/12, Xavier Hanin <[EMAIL PROTECTED]>: > at all with these characters. The solution is to set the property " > ivy.default.always.check.exact.revision" to false, then Ivy will avoid > testing what you ask as an exact revision first, and hopefully it will fix > your problem. By setting the property above, I now get a different error: [ivy:retrieve] local.tomcat: no ivy file nor artifact found for [ ops4j | org.ops4j.pax.wicket | [0.3,1.0] ] [ivy:retrieve] tried http://localhost:8084/artifacts/ivy-repo/ops4j/org.ops4j.pax.wicket/ivys/ivy-[0.3,1.0].xml [ivy:retrieve] tried http://localhost:8084/artifacts/ivy-repo/ops4j/org.ops4j.pax.wicket/ivys/ivy-[[0.3,1.0]].xml [ivy:retrieve] tried http://localhost:8084/artifacts/ivy-repo/ops4j/org.ops4j.pax.wicket/jars/service-[0.3,1.0].jar [ivy:retrieve] WARN: module not found: [ ops4j | org.ops4j.pax.wicket | [0.3,1.0] ] I'm expecting that it will try the following jar files in succession: e.g. http://.../service-0.3.jar http://.../service-0.4.jar ...etc.. http://.../service-1.0.jar Do I have the right understanding of revision ranges ?
Ok, the message is not clear, but I think Ivy actualy tried to find a version within the version range. If you activate verbose or debug log (I don't know by heart in which level the information is output), you will see which versions are found by Ivy. Indeed, the behaviour of a version range is not to test 0.3 until 1.0, it is to list the versions available on the server, and take the latest which is within the range. In your case I suspect Ivy hasn't found any version within the range, which could be explained by your http server (if directory listing is not enabled for instance). Debug log should help diagnose your problem, what you can also is try asking for a latest.integration instead of a version range just to see if it works (i.e. revision listing works) or not. Xavier Thanks.
