Thanks Andy, nice workaround. I would of course like to have the more concise syntax of dependsOn ;) I didn't know you could actually call the tasks this way. I found one buried example of this in the documentation after searching. At least I've learned one new thing about gradle in this discussion.
I still don't understand though why so many are against task dependency respecting dependsOn order yet. I've not seen compelling evidence that it is harmful in anyway (at least not more than how it is today). Thanks again Andy for this, I very well might use this approach for my 'macros' :) gretar On Wed, Nov 24, 2010 at 8:05 PM, Andrew Spina <[email protected]> wrote: > As a potentially alternate solution, is there a way for one task to > explicitly execute another task? Perhaps Gretar could write something like > this: > > task secureDeploymentOfSomething << { > setupSecurity.execute() > deploySomething.execute() > } > > Gretar's use case sounds a little bit like a macro to me (esp. given that > 'gradle setupSecurity deploySomething' does the job) > > Just a thought... > > Andy > > On Nov 24, 2010, at 11:14 AM, Gretar Arnason wrote: > > Hi Robert. > > On Wed, Nov 24, 2010 at 3:20 PM, Robert Fischer < > [email protected]> wrote: > >> Yeah, we really don't want dependsOn to imply an ordering, because >> else builds will just end up being a broken mess of unnecessary >> bookkeeping. It would also kill the ability to do concurrent build >> steps (should we have such a thing). >> >> ~~ Robert. >> >> > I'm not following this logic, I would assume that if the general case is > that ordering is not guaranteed then how would respecting the order change > anything for those who do not assume any specific order? So for those > assuming no specific ordering, explicit ordering should not harm them. > I would also think that it would be better to tag concurrent steps/tasks > explicitly rather than have some implicit concurrency running in the build? > But then again I might not have the full picture of what you are thinking > when you say concurrent steps :) > > All that aside, does anyone have any suggestions how to be able to run > tasks b and a in that order without renaming them (which in my mind would > lead to broken mess of unnecessary bookkeeping) or introducing dependencies > between them. > > Maybe a more concrete example might help: > > task setupSecurity << { > ... > } > > task deploySomething << { > ... > } > > task secureDeploymentOfSomething (dependsOn: ["setupSecurity", > "deploySomething"])<< { > ... > } > > Now under most circumstances I use the deploySomething task but now and > then I need to be able to setup the security beforehand and I don't want to > do it by saying task deploySomething(dependsOn: setupSecurity). > And I'd like to have a more convenient way of starting the tasks other than > using >gradle setupSecurity deploySomething (which incidentally seems to > respects the order of task given). > > thanks > gretar > > > >
