Project status always reverting to integration

(Justin Ryan) #1

I’m seeing the status in my generated ivy.xml file as always “integration”, even though I have status=‘release’ in either the build.gradle or the I’ve tracked it to the ModuleDescriptor for the :archives configuration, which is getting set via BasePlugin.configureConfigurations, which has these two lines (line 169, in m7):

ConfigurationContainer configurations = project.getConfigurations();

project.setProperty(“status”, “integration”);

That’s overriding what I had up until that point. It’s very explicitly overriding the status, why? Or better stated, how should I set the status on the project, so that the ivy.xml gets marked as “release”?

(Justin Ryan) #2

If I move the status further down into the build.gradle, past the “apply plugin”, I properly get the status I set. Blah. This is a work around, but this still prevents me from specifying the status on the command line via -P or via I’m really curious how this isn’t messing up other gradle developers, unless I’m missing something. If someone can chime in if they have this problem, I can file a bug.


This sounds like a bug to me. I’ve raised it as GRADLE-2087.

I’m guessing that this isn’t messing up other gradle devs because they aren’t taking trying to control the published status in ivy.xml.

(Peter Niederwieser) #4

Is that ‘project.status’ property even documented anywhere? First time I hear about it.

(Justin Ryan) #5

I’m guessing people are taking the Maven approach and using -SNAPSHOT to denote the status of a build. In the Ivy world, not only do we have fine control of the status, we can define our own statuses. And only in the definition do we status if a build is a mutable “snapshot” release.

It’s not documented and that concerned me a little bit, since it plays so heavily into how you calculate the next version in ivy.

Daz, thanks for creating the bug.


Well ‘status’ only plays a role in dependency resolution if you use the “latest.release” style of dynamic version specification. I don’t think this is a common pattern.

I personally don’t like this usage much, as it means that we need to download and parse the ivy.xml for each revision in order to see which ones are flagged as ‘release’. Other schemes rely only on the version number, making it a lot easier to resolve a dynamic revision.

But we have no plans to remove this functionality. It’s a legacy of our ivy origins; many ivy features still work to some extent even though they are not tested or documented in Gradle.

(Gradle Jira) #7

The documentation still states the default should be ‘release’ - see

Could the docs be updated until the bug is fixed?

I found uploading to ivy it defaulted to ‘integration’ if no status was explicity set.