Agreed. On Wed, Mar 20, 2013 at 4:09 PM, Luke Daley <[email protected]>wrote:
> > 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 > > > -- 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
