I think it just makes me uncomfortable because it can't be relied on in
any case but the very simplest one. If all you have is one task with
dependsOn and the dependent tasks aren't referenced in any other
dependsOn and there are no transitive dependencies that might affect the
order, then it works. Otherwise, it might look to work one day unless
you later add any of the above (and perhaps other things I haven't
thought of) and then it stops executing in the order you want.
Hmmm... I think my issue is that you want something specific but because
of the lack of a proper way to specify that relationship, you are hoping
that dependsOn will fit the bill. The OCD engineer in me would rather
have a way to explicitly define what you want rather than relying on
potentially fragile behavior as a side-effect of something else. :)
It seems like the 'macro' idea described by Andy is closer to an
explicit way of specifying what is really going on.
-Paul
On 11/24/2010 3:33 PM, Gretar Arnason wrote:
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]
<mailto:[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]
<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
