[GRADLE-2329] Resolution issue during Ivy version conflicts with explicit artifact specification Created: 30/May/12 Updated: 10/Feb/17 Resolved: 10/Feb/17 |
|
Status: | Resolved |
Project: | Gradle |
Affects Version/s: | 1.0-milestone-9 |
Fix Version/s: | None |
Type: | Bug | ||
Reporter: | Brian Harris | Assignee: | Unassigned |
Resolution: | Won't Fix | Votes: | 1 |
Description |
Ivy project A depends on B and C. Both B and C depend on X. X's ivy.xml has a 'runtime' configuration and a jar attached to it called x-$VERSION.jar where $VERSION matches X's version. B's ivy.xml has this dependency <dependency org="x" name="x" rev="1.0" conf="runtime"> <artifact name="x-1.0" ext="jar" type="jar"/> </dependency> C's ivy.xml has this dependency <dependency org="x" name="x" rev="2.0" conf="runtime" /> My conflict resolver chooses version 2.0, but later when it downloads the required artifacts (over http) it tries to download a jar called x-1.0.jar. In other words it tries to download something like this: http://my/ivy/repo/x/2.0/lib/x-1.0.jar It seems that after resolving the conflict, Gradle still tries to honor the jar names specified for the losing version. And then because it cannot find that jar, my build fails. What should be happening here? |
Comments |
Comment by Brian Harris [ 30/May/12 ] |
IMHO a warning should be issued and the build should proceed. |
Comment by Niclas Hedhman [ 03/Jun/12 ] |
Is this an Ivy core issue or an issue about how Gradle uses Ivy? It seems to me that this is core Ivy problem, that the artifacts of B is mixed up into the artifacts of C. |
Comment by Brian Harris [ 04/Jun/12 ] |
I think it's a Gradle issue, my tests show that standalone Ivy evicts 1.0 and doesn't attempt downloading x-1.0.jar. |
Comment by Brian Harris [ 04/Jun/12 ] |
Below is a pretty nasty workaround diff --git a/subprojects/core-impl/src/main/groovy/org/gradle/api/internal/artifacts/ivyservice/DefaultLenientConfiguration.java b/subprojects/core-impl/src/main/groovy/org/gradle/api/internal/artifacts/ivyservice/DefaultLenientConfigura tion.java index c8c0107..c7f9652 100644 --- a/subprojects/core-impl/src/main/groovy/org/gradle/api/internal/artifacts/ivyservice/DefaultLenientConfiguration.java +++ b/subprojects/core-impl/src/main/groovy/org/gradle/api/internal/artifacts/ivyservice/DefaultLenientConfiguration.java @@ -20,6 +20,8 @@ import org.gradle.api.internal.CachingDirectedGraphWalker; import org.gradle.api.internal.DirectedGraphWithEdgeValues; import org.gradle.api.internal.artifacts.ivyservice.ivyresolve.ArtifactResolveException; import org.gradle.api.specs.Spec; +import org.slf4j.Logger; +import org.slf4j.LoggerFactory; import java.io.File; import java.util.*; @@ -32,6 +34,7 @@ public class DefaultLenientConfiguration implements ResolvedConfigurationBuilder private final Set<UnresolvedDependency> unresolvedDependencies = new LinkedHashSet<UnresolvedDependency>(); private final CachingDirectedGraphWalker<ResolvedDependency, ResolvedArtifact> walker = new CachingDirectedGraphWalker<ResolvedDependency, ResolvedArtifact>(new ResolvedDependencyArtifactsGraph()); + private static final Logger LOGGER = LoggerFactory.getLogger(DefaultLenientConfiguration.class); public DefaultLenientConfiguration(Configuration configuration, ResolvedDependency root) { this.configuration = configuration; @@ -112,7 +115,13 @@ public class DefaultLenientConfiguration implements ResolvedConfigurationBuilder Set<File> files = new LinkedHashSet<File>(); for (ResolvedArtifact artifact : artifacts) { - File depFile = artifactFileResolver.getFile(artifact); + File depFile = null; + try { + depFile = artifactFileResolver.getFile(artifact); + } catch (Exception e) { + LOGGER.warn("Swallowing file resolution error (workaround for http://issues.gradle.org/browse/GRADLE-2329): " + e.getMessage()); + LOGGER.debug("Swallowing file resolution error (workaround for http://issues.gradle.org/browse/GRADLE-2329)", e); + } if (depFile != null) { files.add(depFile); } |
Comment by Daz DeBoer [ 11/Jul/12 ] |
I haven't confirmed the behaviour, but this sounds like a bug. We don't have automated tests for conflict resolution where ivy files have artifacts explicitly declared on dependencies. To me, B's ivy.xml looks very strange: is it normal for the <artifact> element to declare the version in the artifact name? (I've never used this feature of ivy) |
Comment by Benjamin Muschko [ 15/Nov/16 ] |
As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub. We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to. Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:
We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle! |
Comment by Benjamin Muschko [ 10/Feb/17 ] |
Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved. |