[
https://issues.apache.org/jira/browse/IVY-818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12628890#action_12628890
]
Shawn Zeller commented on IVY-818:
----------------------------------
I had the same problem trying to use the grizzly project last night. From my
ivy settings xml file
<ibiblio name="java-net-maven1"
root="http://download.java.net/maven/1" pattern="${java.net.maven.pattern}"
m2compatible="false"/>
<ibiblio name="java-net-maven2"
root="http://download.java.net/maven/2/" m2compatible="true" />
and here's a depedency that has the problem
<dependency org="com.sun.grizzly" name="grizzly-servlet-webserver"
rev="1.8.5.4" />
> Ivy ibiblio resolver chokes on variables while checking descriptor consistency
> ------------------------------------------------------------------------------
>
> Key: IVY-818
> URL: https://issues.apache.org/jira/browse/IVY-818
> Project: Ivy
> Issue Type: Bug
> Components: Maven Compatibility
> Affects Versions: 2.0-RC1
> Environment: Ubuntu 8.04, ivy svn rev: 657553
> Reporter: Robert Newson
>
> The ibiblio resolver in trunk has a new facility for parsing
> maven-metadata.xml in order to find the latest snapshots. Unfortunately it
> doesn't work if the version numbers in the poms are variables, that is, our
> pom's have ${subproject-version} in them.
> When encountering these, Ivy throws this;
> java.text.ParseException: inconsistent module descriptor file found in
> 'http://mvn.mycompany.com/maven2/<removed>/1.2.0-RQA2-20080518.055623-736.pom':
> bad revision: expected='1.2.0-RQA2-SNAPSHOT' found='${subproject-version}';
> at
> org.apache.ivy.plugins.resolver.BasicResolver.checkDescriptorConsistency(BasicResolver.java:575)
> at
> org.apache.ivy.plugins.resolver.BasicResolver.getDependency(BasicResolver.java:252)
> at
> org.apache.ivy.plugins.resolver.IBiblioResolver.getDependency(IBiblioResolver.java:417)
> at
> org.apache.ivy.plugins.resolver.ChainResolver.getDependency(ChainResolver.java:124)
> at org.apache.ivy.core.resolve.IvyNode.loadData(IvyNode.java:169)
> at org.apache.ivy.core.resolve.VisitNode.loadData(VisitNode.java:257)
> at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:610)
> at
> org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:696)
> at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:618)
> at
> org.apache.ivy.core.resolve.ResolveEngine.getDependencies(ResolveEngine.java:501)
> at
> org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:233)
> at
> org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:191)
> at org.apache.ivy.Ivy.resolve(Ivy.java:502)
> at org.apache.ivy.ant.IvyResolve.doExecute(IvyResolve.java:232)
> at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:277)
> It seems Ivy verifies that the pom matches the metadata file, laudable in
> itself, but doesn't know that ${subproject-version} expands to the expected
> value. Setting that as a property did not help.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.