On 01/02/2013, at 11:59 PM, Szczepan Faber 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"). > > "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"
This is a good way of thinking about it. > > 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. This is still an open question: whether 2.0 supports only decoupled projects, or whether the old model is still there for you to opt to use, or whether there is some new way to couple projects together. Either way, the aim is that the default in Gradle 2.0 will be that a project is decoupled from all other projects unless stated otherwise. > Also, I > think the biggest (possibly only) value of the switch is > discoverability & trying-on. Probably. It can depend where the coupling is. For example, if the only coupling is in, say, assembling some aggregate javadocs, and this is only done for CI and release builds, then I can run with this switch for dev builds, but I can't switch it on for the build as a whole. > 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 > > -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
