It's not the most ideal solution, but you can use a method to make Andy's
solution a bit prettier:
[code]
def doFirst(Task[] preTasks) {
preTasks*.execute()
}
...
task secureDeploymentOfSomething << {
doFirst(setupSecurity, deploySomething)
}
[/code]
On Wed, Nov 24, 2010 at 12:33 PM, Gretar Arnason <[email protected]>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]> 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
>>
>>
>>
>>
>
--
Learn from the past. Live in the present. Plan for the future.
Blog: http://www.townsfolkdesigns.com/blogs/elberry
jEdit <http://www.jedit.org> - Programmer's Text Editor
Bazaar <http://bazaar.canonical.com> - Version Control for Humans
