Adam Murdoch-3 wrote:
>
>
> There's two things going on here.
>
> First, when a configuration is resolved (for example, when iterating over
> its files) the result is cached and the same set of files is always
> returned.
>
> Second, the afterEvaluate { } closure of a project is executed immediately
> after the build script for the project is executed, but not necessarily
> after the other build scripts which affect the project have been executed.
>
Ah yeah, I figured that out a bit later on and stuck this in the
afterEvaluate bit:
standardProjects(exclude:project).each {
project.evaluationDependsOn(it.path) }
Although now I'm thinking its obviously too late to do this since its after
the eval of that project. Guess I'll move that outside into the rootProject
script somewhere...
Adam Murdoch-3 wrote:
>
> In your example, the build script for :anotherProject executes first. When
> its afterEvaluate { } closure executes, the build scripts for :core and
> :util projects have not been executed. The println causes the
> configuration to be resolved and the result cached. And since :core's
> build script has not been executed, the dependencies for ecs and xstream
> have not been added.
>
> You're supposed to get an exception when you modify a configuration in
> some way after it's been resolved, but you've run into a situation where
> it's broken: http://jira.codehaus.org/browse/GRADLE-1120
>
> Configuration ordering is a bit of a problem at the moment, and can lead
> to some really confusing behaviour. We want to make some changes to
> improve this.
>
Yeah +1 for this. I'm loving gradle, its been such a breath of fresh air
converting our old, fairly complex Ant build to it, its only the last couple
of days days where I've had to start tying different types of dependencies
together for generating manifest classpaths and distribution jars that I've
started to struggle.
Adam Murdoch-3 wrote:
>
> One part of the solution will be to have things fail when you try to
> configure something which has already been 'executed'. Adding dependencies
> to a configuration after it has been resolved is an example of this. Or
> adding dependencies to a task after the graph has been built. Or changing
> a task property after the task has executed. And so on.
>
> Another part will be to provide better ways to declare what your code
> needs. For example, your println really only works once the configServer
> configuration has been fully configured. So we might offer a
> whenConfigured { } method on the Gradle domain objects, so you can do
> something like:
>
> configurations.configServer.whenConfigured { println ... }
>
> Or perhaps you might be able to say that the afterEvaluate { } closure
> dependsOn the configServer configuration.
>
Configuration.whenConfigured sounds like a decently elegant way to do this.
In the meantime, I guess I'll be reining in my printlns :)
Adam Murdoch-3 wrote:
>
> The final part is to have Gradle take care of more (or all) of the
> ordering for you. For example, Gradle can figure out that that the
> whenConfigured { } closure above must be deferred until after the :core
> and :utils projects have been configured, because of the transitive
> project dependencies in the configServer configuration.
>
Couldn't you end up with some confusing conflicts between this and
evaluationDependsOn between projects though? I guess evaluationDependsOn
could (in most use cases) disappear if gradle could figure out evaluation
dependencies by looking at how configuration dependencies are laid out?
Thanks a lot for the explanation, things are much clearer now :)
Cheers,
Chris.
--
View this message in context:
http://gradle.1045684.n5.nabble.com/printing-configuration-dependencies-alters-the-list-of-files-tp3232403p3233296.html
Sent from the gradle-user mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
