What about adding the dependencies conditionally if "doTheWholeStuff" is in
the list of tasks to perform?
Something like:
if (gradle.startParameter.taskNames.contains('doTheWholeStuff')) {
runSomeExternalStuff.dependsOn uploadSomeStuff
uploadSomeStuff.dependsOn assembleStuff
}
Regards,
Steinar
On Thu, Nov 25, 2010 at 12:40 PM, Gretar Arnason <[email protected]>wrote:
> Ok Dierk and Robert, point accepted :)
>
> Maybe I'm too ANT contaminated, plus I'm almost at the end of porting a
> huge system build from ANT to gradle and was hoping to not have to change
> the whole architecture of things. So I'm struggling with these contextual
> requirements, specially with setting up an assembler/installer (a
> integration project - no specific compiling involved), which has many
> outputs depending on context (depending on customers for example)
> I've not had any problems setting up dependency hierarchies when building
> modules of the system but the picture is totally different when I have this
> integration project (which has a lot of 'macros'). Maybe I will be allotted
> some time at my company to re-make the integration project using gradle
> proper (one can only hope).
>
> Adam,
> to give you a little glimpse of what I was trying to achieve is to
> basically collapse into one task the calling of many tasks (in order
> specific way) - to simplify the usage for developers. So instead of using
> from command line something like (has even been shortened)
> >gradle assembleStuff uploadSomeStuff runSomeExternalStuff
> I would like to be able to do
> >gradle doTheWholeStuff
> which would do the same as the line above and it should run it in the same
> order as is in the command line.
> However I would still want to retain being able to do
> >gradle uploadSomeStuff (here I don't want the assembleStuff)
> I'm still not sure I'd want to connect the tasks explicitly together since
> it depends on the context whether assembleStuff is something I want to
> happen. Plus I might want to reuse assembleStuff in some other context.
>
> If starting from scratch I would probably do this a lot differently but
> this is the thing I have to work with now.
> I'm just having difficulties seeing why ordering the tasks by the order
> received is any worse that ordering alphabetically. I do concur that relying
> on the dependsOn order is prone for errors and maybe it is good in this case
> to just not give the developer the option to screw up. It still nags be that
> we have many examples of technologies trying to restrict developers (to do
> the right thing) just resulting in developers jumping to some other
> technology that answers their demands.
> Don't get me wrong, I love gradle, I wouldn't be investing my time here if
> I didn't. It's just that I am leaning toward the mentality that its ok to
> let the developers learn from their mistakes (but of course some people
> never learn - hopefully not me though :) ).
>
> Thanks for a good discussion, I appreciate the time you put into
> responding.
> regards
> gretar
>
>
>
>
>
>
> On Wed, Nov 24, 2010 at 10:31 PM, Robert Fischer <
> [email protected]> wrote:
>
>> "dependency-order-by-declaration-sequence is in my eyes one of the
>> features
>> that makes so many ANT builds difficult to maintain. You need to know the
>> whole
>> build to safely make a tiny change in the dependency chain and you
>> have to make those
>> changes more often. You even have to know the whole build to _use_ it
>> correctly!"
>>
>> This is what I was getting at in saying that dependency ordering
>> becomes a mess of fragile bookkeeping. Conflicting dependency
>> resolutions orders—argh!
>>
>> ~~ Robert.
>>
>> On 24 November 2010 17:20, Dierk König <[email protected]> wrote:
>> >> The execution order is defined when the output-input characteristic
>> >> requires it.
>> >
>> >
>> > I'm probably not familiar enough with gradle to know exactly what you
>> mean
>> > by 'output-input characteristic'
>> > could you elaborate further
>> >
>> > Gradle tasks can define what they take as input and what they produce as
>> > output.
>> > And many tasks do.
>> > If task x produces an output artifact that is consumed as input by task
>> y
>> > then a
>> > dependency on both x and y is guaranteed to be in executed sequence:
>> first
>> > x, second y
>> > (unless the output is up to date and x can be skipped).
>> > x -> artifact -> y
>> > a.dependsOn = [y, x] // declare the 'what', not the 'how'
>> > This behavior is one of the distinctively mindful design choices of
>> Gradle.
>> > Imagine the sequence of dependsOn declarations would define the order.
>> > You can get a conflict with the output-input chain sequence. Now - who
>> wins?
>> > That in my opinion is the best example where imposing an
>> > order-by-declaration-sequence
>> > limits the build system.
>> > It is not the main reason, though. The reason - on an architectural
>> level -
>> > is that
>> > dependencies _have_ no order by nature.
>> > Also, with an imposed order, you would care too much about the "how"
>> where
>> > you should
>> > rather care about than the "what".
>> > cheers
>> > Dierk
>> > P.S. dependency-order-by-declaration-sequence is in my eyes one of the
>> > features
>> > that makes so many ANT builds difficult to maintain. You need to know
>> the
>> > whole
>> > build to safely make a tiny change in the dependency chain and you have
>> to
>> > make those
>> > changes more often. You even have to know the whole build to _use_ it
>> > correctly!
>> > P.P.S. In case you haven't guessed, yet: I love Gradle!
>> > Kudos to Hans and Adam!
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>
