On 01/02/2013, at 1:03 PM, Luke Daley <[email protected]> wrote:
> > On 01/02/2013, at 12:59 PM, Szczepan Faber <[email protected]> > wrote: > >> I agree with criticism of the current --configure-on-demand switch. >> >> Still, command line switch like >> --gradle-2.0-model --new-project-model feels a bit awkward and too >> generic to me. I'd rather have something like --decoupled-projects >> (don't like it either, just throwing out - it's using the term that we >> already documented officially "decoupled projects"). > > Turning this on doesn't turn on decoupled projects, it requires it. We could > flip it and say that by setting this flag you are telling us that you have > decoupled projects and we will perform our rad optimisations. > > This has some appeal. Just realised this is exactly the same as what you said below. Apologies. > >> >> "New project model" term does not associate well in my head (it seems >> to tell me that there's a new project API, new classes, etc.). >> Paraphrasing Adam a bit, I would change: >> >> "please run my build with the new project model and switch on whatever >> nifty features this enables" >> >> into: >> >> "I made sure my projects are decoupled, please switch on whatever >> nifty features this enables" >> >> Nevertheless, I see the point of Luke's comments on the PR effect of >> "new project model", "Gradle 2.0 model". If that's the direction, I'm >> happy to execute it :) >> >> My understanding is that this switch will be gone in Gradle 2.0 (or >> Gradle X.0) when Gradle projects will be decoupled by default. Also, I >> think the biggest (possibly only) value of the switch is >> discoverability & trying-on. Typically, the decoupled multi-projects >> will have gradle.properties configured, not requiring to use the flag >> every time. >> >> Cheers! >> >> On Thu, Jan 31, 2013 at 3:39 PM, Ken Sipe <[email protected]> wrote: >>> +1 >>> >>> Sent from my iPhone >>> >>> On Jan 31, 2013, at 3:08 AM, Luke Daley <[email protected]> wrote: >>> >>>> >>>> On 31/01/2013, at 6:31 AM, Adam Murdoch <[email protected]> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> I think we need a new name for the 'configure-on-demand' feature switch. >>>>> What it actually does is enable a new decoupled project model, which >>>>> Gradle can take advantage of to skip configuring projects that are not >>>>> required, and also (optionally) execute stuff in parallel, and later do >>>>> other interesting things like allow project dependencies in build script >>>>> classpaths, build aggregation, and more. This new model will become the >>>>> default in Gradle 2.0 (and, in fact, it is currently the definition of >>>>> Gradle 2.0). >>>>> >>>>> So, I think what we need is some way to say 'please run my build with the >>>>> new project model and switch on whatever nifty features this enables', >>>>> rather than the current way to say 'please switch on this nifty feature >>>>> and if that means using the new project model then thats ok'. Parallel >>>>> execution is a bit of a special case and probably should keep its own >>>>> flag. >>>> >>>> Makes a lot of sense. >>>> >>>> This seems to be hard to name. Left field idea… including some marketing >>>> in this and calling it the Gradle 2.0 project model (opposed to the more >>>> technical “decoupled”) and using that as the basis for the switch name? >>>> >>>> Pros: >>>> >>>> 1. Creates some anticipation for Gradle 2.0, and whatever other marketing >>>> benefits >>>> 2. Is general enough to allow us to incorporate whatever changes are >>>> necessary as part of the new model >>>> >>>> Cons: >>>> >>>> 1. It's a certain level of commitment/promise >>>> 2. Doesn't give much of an indication of what the difference is (i.e. >>>> you'd need to read the docs) >>>> >>>> >>>> Haven't thought about this too much, but there seems to be a certain >>>> appeal of being able to enable Gradle 2.0 mode while it's incubating for a >>>> user POV. >>>> >>>> -- >>>> Luke Daley >>>> Principal Engineer, Gradleware >>>> http://gradleware.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 >>> >>> >> >> >> >> -- >> Szczepan Faber >> Principal engineer@gradleware >> Lead@mockito >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> > > -- > Luke Daley > Principal Engineer, Gradleware > http://gradleware.com > -- Luke Daley Principal Engineer, Gradleware http://gradleware.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
