Hi all,
in the London Gradle class we had an interesting discussion about the order
dependence in Gradle scripts. Here are some use cases:
1.) You want to define a rule that add a dynamic property to all jar task:
tasks.withType(Jar).allObjects { jar -> jar.osgify = false }
If you specify a jar task before this, which sets osgify to true, this will
be overridden by the rule. Therefore you need to specify it at the beginning
of the build script.
2.) You want to define a rule that modifies a task based on its dynamic
properties.
tasks.withType(Jar).matching { jar -> jar.osgify }.allObjects { jar ->
jar.doLast { // do something }}
Let's add a jar task like: task myJar(type: Jar) { osgify = true }
If you do this after the rule is specified, the rule is applied before
osgify is set to true. Either you need to specify the rule after all jar
tasks are added. This is bad, as you might want to do this in a plugin which
requires that some rules are specified in the beginning. A better solution
for this would be to specify the rule in an afterEvaluate closure. But this
is also far from perfect. For example if you have multiple statements that
should be done at the end and which have an order dependence. Having just a
list makes things awkward, fragile or even impossible. The same is of course
true for the first rule.
How to improve: The build script itself defines a default 'configuration'
(has nothing to do with a dependency configuration). We could define
configurations that depend on default or other configurations.
configuration('actOnDynamicProp') {
dependsOn configuration('default')
// add an action if dynamic prop is set
}
Making the default build script on some other configuration is harder to
achieve. One option would be compile transformations. But we would need to
search them recursively through the applied plugins.
Thoughts?
- Hans
--
Hans Dockter
Founder, Gradle
http://www.gradle.org, http://twitter.com/gradleorg
CEO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
