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
