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").
"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
