With the new Ivy publishing support in Gradle 1.3 it would be possible to implement Ivy deliver so that one could get reproducible builds. But I was wondering whether it would be easy to also add support for dynamic resolve mode similar to Ivy’s - i.e. using the dependency’s ‘revConstraint’ during resolution rather than the ‘rev’ attribute?
Hi Detelin,
Can you please tell us a bit more about how and why you use this functionality.
Sure,
In our company products are not really using any semantic versioning, instead, for each official release we have one major.minor.micro version, for example if current release is ‘1.0.0’, next release (possibly next year) would be ‘1.1.0’, or it can even be ‘2.0.0’ - the actual version is not chosen based on the changes in the products, but mostly for some marketing reasons - all products are required to use one and the same version 
So when doing let’s say ‘1.0.0’ release, we create a branch, and trunk is switched to the next version chosen, e.g. ‘1.1.0’ - then this version is used for the next year or so, before doing the next release. While developing on trunk during this period, all products normally use ‘latest.milestone’ when declaring dependencies to other products (products produce a milestone once per week or more often).
However, sometimes it happens that a product must introduce some non-backward compatible change - in this case the corresponding team informs the affected products that they must adapt accordingly. So once the product produces a milestone with this breaking change, all affected products must do the same asap. With this approach, one can almost certainly resolve the latest top-level product thereby also gathering the milestones of its dependencies to produce a working solution.
The problem comes when one needs to resolve an older milestone of a top-level product - this old milestone would be resolved with the latest milestones of the other products and if there was any breaking change since it was built, it would most certainly fail to run.
I was thinking that if we use Ivy deliver to preserve the static versions of the dependencies when a product is uploaded, we can use the ‘dynamic’ resolve mode when we want to resolve the latest milestone, but fall back to static resolve mode if we want to resolve an older milestone.
Do you think this would work?
Regards,
Detelin
Hi Luke - Well, I think Ivy adds attributes ‘rev’ and ‘revConstraint’ for a good reason. Both, ‘static’ and ‘dynamic’ resolve modes are essential use cases. The first is need for reproducibility and the second one for further development and fix management.
It is impossible to always decide before publishing if the results shall be resolved statically or dynamically in the future.
Instead, always publishing with Ivy delivery will produce a complete Ivy descriptor and everyone then is free to choose the resolve mode as needed.
It would be very much appreciated if Gradle would allow to switch between the ‘default’ and ‘dynamic’ resolve mode as defined by Ivy. Thanks…/Thomas
There are a variety of ways that we are contemplating to provide reproducibility. Do you also have pure Ivy consumers of your dependencies or would a special Gradle way to achieve that also work for you?
This discussion is also related to http://forums.gradle.org/gradle/topics/_ivypublish_dynamic_version_in_ivy_xml_are_not_replaces_when_publishing which is also related to exact reproducible (development) builds.
Hans - Since Gradle 1.3 it is not a question about reproducibility anymore. Now the focus switches from the publish to the resolver side.
Pure Ivy supports the dynamic resolve mode no matter if the artifacts were published by Gradle or pure Ivy. It is a limitation of Gradle always using the ‘default’ resolve mode and not being able to to switch to the ‘dynamic’ resolve mode…/Thomas