On 22 Aug 2014, at 1:09 am, Szczepan Faber <szcze...@gmail.com> wrote:
> Hey,
>
> Currently, we don't detect a change to the configuration after it was
> resolved, when the change happens within hierarchy. For example:
>
> configurations {
> foo
> bar.extendsFrom foo
> }
>
> configurations.bar.resolve()
> //add dependency to bar, via configuration hierarchy:
> dependencies { foo "org.lib:1.0" }
>
> Is this by design?
No, it’s a bug. There’s a similar bug when a configuration is reached via a
project dependency.
Once a configuration is involved in a resolution, it should be locked and
further mutations should fail. The error message could easily tell you why the
configuration is locked as we have this information, and could possibly include
clues as to where the resolution was triggered (for example, which build script
or task happened to be running at the time, but not necessarily file and line
number of the statement).
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
CTO Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
