[GRADLE-2715] Cannot resolve an ivy module with custom ivy status Created: 20/Mar/13  Updated: 03/Sep/13  Resolved: 03/Sep/13

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: 1.8-rc-1

Type: Bug
Reporter: Gradle Forums Assignee: Unassigned
Resolution: Fixed Votes: 0

Issue Links:
dependent
dependent by GRADLE-2716 Provide support for resolving custom ... Resolved

 Description   

I have a legacy ivy repository where jars were built with a custom ivy status. Is there a way to tell Gradle about accepting a custom ivy status? If I try to pull from this repo, gradle fails with an error message about "bad status".



 Comments   
Comment by Gradle Forums [ 20/Mar/13 ]

I'm afraid there not currently any way to use Gradle's built-in repository implementations when the contained modules have a custom status.

One way to get it to work would be to use an appropriately configured Ivy DependencyResolver instance: you can see a few examples of these in our integration tests (no other docs, sorry). You can check these out at [1]https://github.com/gradle/gradle/tree....
----------------------------------------------------------------------------------------
[1] https://github.com/gradle/gradle/tree/master/subprojects/core-impl/src/integTest/groovy/org/gradle/integtests/resolve/custom

Comment by Gradle Forums [ 20/Mar/13 ]

It appears that org.gradle.api.internal.artifacts.ivyservice.DefaultSettingsConverter.convertForResolve is taking the URLResolver (that I'm creating) and overriding all the settings, which specifically include our custom statuses. The act of calling addResolver is what is setting the IvySettings from IvySettingsFactory. The examples given by Daz don't cover the settings of IvySettings, they only really set the patterns.

It doesn't seem possible in 1.4 to set custom statuses.

Comment by Gradle Forums [ 20/Mar/13 ]

Right, sorry for the misdirect. When we construct a custom IvySettings instance and add your resolver to it, we effectively overwrite any settings that were configured when the resolver was constructed. So it's not possibly to update the set of known statuses to use when resolving.

I see 2 ways to tackle this:
1. Use a custom IvyResolver implementation that doesn't validate the status in an ivy.xml file against the list of known status values. (This code is in org.apache.ivy.plugins.resolver.AbstractResolver)
2. Fix Gradle so that the built-in repository implementations don't fail if ivy.xml contains an unknown status. (This code is in org.gradle.api.internal.artifacts.repositories.resolver.ExternalResourceResolver, which is an inlined copy of the code from AbstractResolver).

If you're interested in pursuing 2., I'd be happy to help out. This would involve:
1. Removing the code that does the validation (which seems kind of pointless).
2. Adding some integration test coverage for resolving modules with 'custom' ivy status.

  • Resolving with a static version (eg 1.0)
  • Resolving with 'latest.integration'
  • Resolving with 'latest.custom'

The first step is pretty trivial, and there are good examples of similar tests in org.gradle.integtests.resolve.ivy.IvyDynamicRevisionResolveIntegrationTest. We'd appreciate the contribution.

Generated at Wed Jun 30 12:29:31 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.