Here's an idea. I haven't tried this, so there might be issues.
1) Define a "pre-task" that all normal tasks (not clean tasks) depend on
("init" in the Ant world).
2) Add a bit of code during configuration phase that watches for the task
graph to be built
3) Once the task graph is built, check if the "clean" is in the task graph
4) If it is, make init depend on the clean task.
This should make sure that clean always gets run before normal tasks, but
doesn't cause it to run unless it was already going to for some reason.
On Sat, Aug 21, 2010 at 5:55 PM, Robert Fischer <
[email protected]> wrote:
> 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
>>
>>
>
--
John Murph
Automated Logic Research Team
