On 22 Aug 2014, at 4:27 pm, Szczepan Faber <szcze...@gmail.com> wrote:
> 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. via child configuration: https://issues.gradle.org/browse/GRADLE-2921 via project dependency: https://issues.gradle.org/browse/GRADLE-1120 > > 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 > > -- Adam Murdoch Gradle Co-founder http://www.gradle.org CTO Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
