Thanks for info!
Do you remember if there is a bug reported in jira about it? I haven't
found it but if you recall that it is already reported I'll look more
thoroughly.
Cheers!
On Fri, Aug 22, 2014 at 3:19 AM, Adam Murdoch
<adam.murd...@gradleware.com> wrote:
>
> 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
>
>
>
--
Szczepan Faber
Core dev@gradle; Founder@mockito
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
