On 20/03/2013, at 7:51 AM, Szczepan Faber <[email protected]> wrote:

> I'd say it's slightly different in a parallel build where I'm fine if unit 
> tests run in parallel with functional tests.

Sure, but most of our CI builds don't use parallel execution.

> 
> Cheers!
> 
> On Wed, Mar 20, 2013 at 3:36 PM, Luke Daley <[email protected]> wrote:
> 
> 
> On 18/03/2013, at 9:27, Szczepan Faber <[email protected]> wrote:
> 
>> I'm wondering if it is the right time to start dogfooding this feature. For 
>> example, we could somewhat model the fast checks ordered before the slow 
>> checks. However, mustRunAfter does not quite fit this use case.
> 
> Isn't this exactly what we want to run unit tests before functional tests?
> 
>> 
>> Cheers!
>> 
>> On Mon, Mar 18, 2013 at 3:26 PM, Luke Daley <[email protected]> wrote:
>> 
>> 
>> On 17/03/2013, at 23:11, Szczepan Faber <[email protected]> 
>> wrote:
>> 
>>> I'm wondering if there's a better name for the 'mustRunAfter' api method. 
>>> 'mustRunAfter' somewhat communicates that the source task will be scheduled 
>>> automatically if the target task is selected. I realise that there might 
>>> not be anything better. I was thinking about something like 
>>> task.orderingRules.after(someOtherTask) or task.orderedAfter(someOtherTask).
>> 
>> This is a good point.
>> 
>> It's reasonable to think that a user would interpret mustRunAfter in this 
>> way. Given that this would mean that mustRunAfter is the same as dependsOn 
>> though, maybe that's enough of a hint that it has different semantics.
>> 
>> I quite like the idea of adding an interim DSL here too…
>> 
>> order.mustBeAfter x
>> order.shouldBeAfter x
>> 
>> Given that the task namespace is a user namespace, we should be conservative 
>> about using it.
>> 
>> The 'order' object could also be queryable for ordering rules.
>> 
>> 
>>> 
>>> On Mon, Mar 18, 2013 at 12:59 AM, Adam Murdoch 
>>> <[email protected]> wrote:
>>> 
>>> On 18/03/2013, at 7:33 AM, Marcin Erdmann <[email protected]> wrote:
>>> 
>>>> As the code has now made it into master shouldn't this issue be marked as 
>>>> resolved?
>>> 
>>> Not quite yet, as there are a few other use cases bundled up in that issue. 
>>> I guess the right thing to do would be to add new issues for the use cases 
>>> we haven't fixed yet and close the issue.
>>> 
>>>> 
>>>> On 07/03/13 09:29, Taytay wrote:
>>>>> As someone who has been following  this bug
>>>>> <http://issues.gradle.org/browse/GRADLE-427>   closely for a while, let me
>>>>> take a moment to thank you for the work you've done here erdi!
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> View this message in context: 
>>>>> http://gradle.1045684.n5.nabble.com/Must-run-after-ordering-tp5710924p5710986.html
>>>>> Sent from the gradle-dev mailing list archive at Nabble.com.
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this list, please visit:
>>>>> 
>>>>>     http://xircles.codehaus.org/manage_email
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>> 
>>>>   http://xircles.codehaus.org/manage_email
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> Adam Murdoch
>>> Gradle Co-founder
>>> http://www.gradle.org
>>> VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
>>> http://www.gradleware.com
>>> 
>>> Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: 
>>> http://www.gradlesummit.com
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Szczepan Faber
>>> Principal engineer@gradleware; Lead@mockito
>>> Join me at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: 
>>> http://www.gradlesummit.com
>> 
>> 
>> 
>> -- 
>> Szczepan Faber
>> Principal engineer@gradleware; Lead@mockito
>> Join me at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: 
>> http://www.gradlesummit.com
> 
> 
> 
> -- 
> Szczepan Faber
> Principal engineer@gradleware; Lead@mockito
> Join me at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: 
> http://www.gradlesummit.com

-- 
Luke Daley
Principal Engineer, Gradleware 
http://gradleware.com

Join me at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: 
http://www.gradlesummit.com


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply via email to