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

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.

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.