That variant on A works. Thanks! I'm looking forward to the explicit ordering, since I'm now extremely wary about any time the "clean" task and any other task might be in the same Gradle run.
~~ Robert. On 21 August 2010 17:40, Adam Murdoch <[email protected]> wrote: > On 22/08/10 2:05 AM, Robert Fischer wrote: > > Requirements: > > 1) If the user asks for both "a" and "b" to be run, I'd like to run "b" > before "a" -- due to Gradle's internal ordering, "a" is coming before "b", > and that's causing issues in the build. > 2) I want to be able to run "b" without "a" executing. > 3) I want to be able to run "a" without "b" executing. > > Suggestions so far are: > > A) Don't ever ask for both "a" and "b" to be run simultaneously, but > instead only ever ask for task "c" to run, which will run "b" then "a". > This is an okay solution as long as I'm explicit in wanting to call "a" and > "b". If they are implicitly called, I'll have to hack around the ordering > at that point. > B) Attach "a" to the end of "b". Which violates requirement #2. > > So is there a better solution? > > The explicit use case is: as a part of my "pull everything together" > phase, I want to run a clean on everything, then a jar on everything. So I > have dependencies on every subproject's "clean" and "jar". > > > You can usually trick Gradle into running things in the correct order. In > your case, you might separate the dependencies onto separate tasks. For > example, in the root project: > > task cleanAll { > dependsOn subprojects*.clean > } > > task jarAll { > dependsOn subprojects*.jar > } > > task buildAll { > dependsOn cleanAll, jarAll > } > > Running the 'buildAll' task will run all the dependencies for 'cleanAll' > and then all the dependencies for 'jarAll'. > > At some point before Gradle 1.0 we will provide some way to state that the > a project's 'clean' task must run before any of the other tasks of the > project. There's a few options for how this might look. The Java plugin will > specify this out-of-the-box, so things should just work. > > > The issue is that I'm getting the following ordering: > :runtime:jar > :lang:clean > :lang:jar > :runtime:clean > :makeDistribution > > The result being that the jar for runtime is blown away before > makeDistribution can get to it. > > I'd really rather avoid having to call "clean" every time I call "jar", > and certainly don't want to have to call "jar" every time I call "clean". > > ~~ Robert. > > On 20 August 2010 20:36, Jim Moore <[email protected]> wrote: > >> Yes. >> >> "gradle c" would work. "gradle a b" would work. Adding "b" at the end >> of "a" would work. And I can think of half a dozen other ways of solving the >> problem as stated with slightly different implications. Without an actual >> use-case, all that can be talked about is vague generalities. If none of >> the current suggestions makes it clear "Oh, I can adapt it in *this* way to >> my problem" then a clearer statement of the problem is needed... >> >> >> On Fri, Aug 20, 2010 at 4:40 PM, Robert Fischer < >> [email protected]> wrote: >> >>> But then if I do "gradle a", I'll always get "b" run, too, right? >>> >>> ~~ Robert. >>> >>> >>> On 20 August 2010 16:37, Matthias Bohlen <[email protected]> wrote: >>> >>>> How about a.doLast(b) ? Does that work? >>>> >>>> Am 20.08.2010 um 22:10 schrieb Robert Fischer: >>>> >>>> I suppose that'll work for the time being. As long as nobody expects >>>> "gradle a b" to work. >>>> >>>> ~~ Robert. >>>> >>>> On 20 August 2010 16:00, Jim Moore <[email protected]> wrote: >>>> >>>>> Depends on your need, but it sounds like you simply need >>>>> >>>>> task c(dependsOn: [a, b]) {} >>>>> >>>>> >>>>> On Fri, Aug 20, 2010 at 3:51 PM, Robert Fischer < >>>>> [email protected]> wrote: >>>>> >>>>>> Is there a way to tell Gradle, "If task A is being executed, make sure >>>>>> to run task B after task A"? I specifically don't want to make Task A a >>>>>> dependency on B (it shouldn't run every time), but I'd like it to run >>>>>> them >>>>>> together now and again, and when that happens they need to run in a >>>>>> certain >>>>>> order. >>>>>> >>>>>> ~~ Robert. >>>>>> >>>>> >>>>> -Jim Moore >>>>> >>>> >>>> >>>> >>> >> -Jim Moore >> > > > > -- > Adam Murdoch > Gradle Developerhttp://www.gradle.org > CTO, Gradle Inc. - Gradle Training, Support, Consultinghttp://www.gradle.biz > >
