If task "b" needs to run before "a" then "a" needs to depend on "b".
Otherwise, you are hoping that gradle will deduce an implied dependency
in this case... which is maybe a little unfair.
What would happen if task "d" depended on ["a", "b"]? Which should
gradle choose?
I think it's probably better to make dependencies explicit. So if "b"
must run before "a" then there is some direct dependency relationship
between them that should be specified. (Though, note that if one
depends on the output of the other that gradle should already figure out
the ordering correctly.)
-Paul
On 11/24/2010 11:14 AM, Gretar Arnason wrote:
Hi Robert.
On Wed, Nov 24, 2010 at 3:20 PM, Robert Fischer
<[email protected]
<mailto:[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
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
