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 > > >
