Hey Peter. Apologies for the delayed reply: vacations and the subsequent catch-up distracted me.
We understand that this is a breaking change, and are working on a way to make this behaviour effectively “opt-in”.
Just to explain: in order to add the appropriate tasks for execution, we need to “resolve” a configuration when we build the task graph. In the past we have not performed a true resolve, but instead we’ve just iterated over project dependencies transitively, ignoring external dependencies. We got away with this because an external module dependency would never transitively reference a project dependency.
True resolution of configurations is required to make dependency substitution work, since we need to resolve the entire graph in order to know what project dependencies are involved, in order to add the appropriate task dependencies. So the current plan is to switch to early resolution only when dependency substitution rules have been defined in your build. This means that an existing build will continue to work unchanged with Gradle 2.5, but adding dependency substitution rules may break builds in unexpected ways.
We also want to reduce the number of ways that builds can break by:
- Detecting when a configuration is changed during task execution, and re-resolving in this case. Such modifications will be deprecated.
- When a task publishes to a repository, consider any configurations that resolve from that repository to be ‘modified’. (We’ll probably want to detect when 2 repositories share a common base URL).
- Allow a build to declare a that a task updates a particular configuration.
Thanks for the feedback. I hope this plan and explanation will satisfy your needs.
Daz