From what I see in the debug logs, latest nightly builds are resolving all regular build dependencies in the configuration phase, before the first task has been started. I don’t know if this is intentional. It kind of works for external deps, but doesn’t work for deps which are first published, and subsequently resolved, by different projects of one and the same build. What’s happening in this case is that the subsequent resolve fails immediately, apparently because it still has the failed resolve (which happened in the configuration phase) cached.
I’m seeing this in 2.5-20150414220019+0000 and ever since. 2.4-rc-1 and 2.5-20150413220018+0000 don’t resolve early, and hence don’t have this problem.
I think this problem can be solved by the same change that causes it to now fail. In this case you could use a substitution rule here to replace the external dependency with a project dependency. Unless there’s a particular reason why a project dependency wasn’t being used in the first place?
My point is that it isn’t safe to assume that a build’s tasks will never have an effect on the resolve result of any of the build’s configurations. Or at least it’s a non-trivial breaking change in a minor version.
The concrete build in question is verifying that the module it published is indeed resolvable from a particular repository using particular credentials. I could probably go in and change the build to use a detached configuration for the verification. But should I have to?
Indeed this is a pretty big change to dependency resolution: as discussed in the link provided by @sterling above, this work was required so that we can construct the correct task dependency graph when we allow substitution of project and external dependencies. (This only applies configurations that are inputs to tasks that are part of the task execution graph.)
The way it should work is that if a configuration is modified during the execution phase, then it will be flagged as needing re-resolving when the resolution result is required. It’s possible that the implementation doesn’t yet deal with the case where the initial (configuration-time) resolve fails but the second (execution-time) resolve would succeed. Is that the case you’re describing?
Daz, not sure what you mean by “if a configuration is modified during the execution phase”. The build doesn’t touch the configuration. All that’s happening is that one project publishes a Maven module, and another project later resolves the module declared as a regular external dependency on a user-defined configuration. Not caching the failure of the ahead-of-time resolve would restore the pre-2.5 behavior for this particular build, but not for the general case where the ahead-of-time resolve doesn’t fail but the publish nevertheless affects the resolve result.
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