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. > > "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 --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
