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
