Peter, Thanks for the info. I would like to know what is the recommended approach to arbitrary ordering and reordering of tasks in gradle. If it is to use dependsOn then I would like to know this, if there is some other approach, what is that? To me, dependsOn appears to not be intended for ordering and reordering of tasks. To me, dependsOn runs contrary to things like dependency injection. I would prefer to avoid dependsOn entirely from what I understand of it. It appears to lead to scripts that are harder to modify than really need be, have undesired complexity and have overly coupled tasks.
Chapter 5. Build Script Basics 5.1. Projects and tasks "A task represents some atomic piece of work which a build performs." With that being said, I want to supply one named task that is a composite of other tasks if need be. I should be able to reuse/recompose other tasks in an order suitable for a different task without regard to the first composite. Command line arguments also have use, however I ought to be able to wrap whatever potential command line argument imaginable into a single simple named task should I not? This allows one to avoid spilling the usage api into other tools. Having the user specify clean on the command line, now they have to know 'how' to do that, and also well maybe they are supposed to -x clean on some other task instead. It seems to me that they would have to then read the build script to determine what is going on with these options, and as always of course they then can make the wrong choice as they are now being unnecessarily required to interact. Also, is the intention that we are not to invoke tasks from within groovy methods, or is it that we are to do it with some other syntax? There are huge drawbacks to not being able to run a task from a groovy method. thanks for any feedback, Levi __________________________________________ --- On Mon, 7/18/11, Peter Niederwieser <[email protected]> wrote: > From: Peter Niederwieser <[email protected]> > Subject: [gradle-user] Re: dependency ordering>>? > To: [email protected] > Date: Monday, July 18, 2011, 9:58 PM > > Levi Yourchuck wrote: > > > > I must have some cognitive disturbance because I am at > a loss. > > If my task C is 'clean' then I cannot dependsOn it in > any task, correct? > > > > You can depend on clean conditionally, for example based on > whether a > particular task is specified on the command line. You can > also defer the > decision what dependsOn relationships to add with > task.dependsOn {}. > Likewise, you can skip a task conditionally with > task.onlyIf {}. > > > Levi Yourchuck wrote: > > > > I mean if my task is create_distro, it seems logical > for me to say > > dependsOn clean correct? > > > It's not completely unreasonable but I'd probably prefer to > leave it up to > whoever invokes Gradle whether to run clean or not. > > > Levi Yourchuck wrote: > > > > Right now I do this pattern: > > > > task create_distro << { > > [ clean, untax, jac, compileJava, classes, > processResources, jar, > > images_jar ].each {println "doing --> > $it";it.execute();} > > } > > > > Is this the recommended approach for ordering tasks? > > > > No, it is discouraged and might stop working at some point. > It's better to > check whether create_distro will be executed and only then > add the necessary > dependsOn relationships. Gradle doesn't offer a clean > solution for this yet > because gradle.taskGraph.whenReady() is too late for adding > dependsOn() > relationships, but checking gradle.startParameter is often > good enough. > > -- > Peter Niederwieser > Principal Engineer, Gradleware > http://gradleware.com > Creator, Spock Framework > http://spockframework.org > Twitter: @pniederw > > -- > View this message in context: > http://gradle.1045684.n5.nabble.com/dependency-ordering-tp4597282p4610788.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 > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
