Yes. You were exactly right. I had a task that was printing out 'configurations.compile.files' in the configuration phase rather than the execution phase. Thanks for the help.
Ryan On Tue, Sep 20, 2011 at 3:16 PM, Adam Murdoch <[email protected]> wrote: > > On 21/09/2011, at 2:09 AM, Ryan J wrote: > > This is probably an easy question, but I can't seem to figure it out. > Say I have a project with several child modules: > > parent > |-- child1 > |-- child2 > > I want to add slf4j-api as a dependency to all child modules: > > subprojects { > dependencies { > compile "org.slf4j:slf4j-api:1.6.1" > } > } > > However, when I try to add more dependencies to one of the child modules: > > project(':child1') { > dependencies { > compile "some other depends" > } > } > > .. I get the error: > > > A problem occurred evaluating root project... > Cause: You can't change a configuration which is not in unresolved state! > > How can I accomplish what I'm trying to do? > > You do exactly what you're already doing. The problem is elsewhere: > When you query the files of a configuration, the configuration is resolved > and the result cached. From then on, you are not able to modify the > configuration, and any attempt to change it results in the error message you > are seeing. So, somewhere in your build script between adding the logging > dependencies and adding the project-specific dependencies, you are, perhaps > unintentionally, querying the files of the compile configuration, and so > flicking it over to unmodifiable mode. > Perhaps have a look for usages of configurations.compile. A common problem > is to mix up configuration time (when the build script executes) and > execution time (when the task executes), and to unintentionally have code > that is supposed to run at execution time, run at configuration time > instead. For example: > task show { > // runs at configuration time > configurations.compile.each { println it } > } > task show { > doLast { > // runs at execution time > configurations.compile.each { println it } > } > } > Another common problem: > copy { > // using .files queries the files immediately > from configurations.compile.files > } > instead of > copy { > // this defers querying until the task is executed > from configurations.compile > } > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
