On Dec 18, 2012, at 2:09 AM, Adam Murdoch <[email protected]> wrote:
> Hi, > > I've written up a rough spec for how we might improve our support for > declarative and customised build runtimes. This covers things like improving > the wrapper, injecting a set of custom plugins and configuration into a > build, splitting up the Gradle distribution and so on. > > The spec is at: > https://github.com/gradle/gradle/blob/master/design-docs/custom-build-runtimes.md Is the main reason to separate between the bootstrapped and the launcher to make the bootstrapper minimal (e.g. make it VCS friendly) but than have a less minimal launcher to reuse Gradle code? I like the idea of a local metadata provider SPI very much. One positive aspect of this for example is that I think current wrapper properties are a bit over engineered to deal with some rare use cases. Delegating rare use cases to a custom provider will make handling those much more flexible and the default metadata simpler. Additionally we could also have a default build environment metadata which can be modified via Gradle commands (either provided by the Launcher or Gradle Runtime). - Define the default Gradle version of your machine via a Gradle command. This version is used if no project specific metadata is provided. Just make it easy for example to switch between Gradle runtime versions. - Provide a command line switch to ignore project metadata and use the default metadata (i.e. a build master wants to try the build with the default version of Gradle). - Provide a command line metadata provider, i.e. a way to describe the build environment you want to run the build with from the command line. - A sub aspect of this is to provide a way to enable/disable the daemon from the command line. Just to make it explicit. Another use case this solves is the separation between the Gradle runtime and custom configuration of the Gradle runtime (i.e. Build Runtime). Right now you have to physically bundle your own build runtime by taking a Gradle runtime, adding init scripts to the init.d directory and packaging this as a zip. With the new mechanisms people wouldn't need to repackage and it will be much easier to provide different build runtimes to different teams/environments. Another thing this will enable is to define a central Gradle version for an organization, not just per project via the wrapper properties. Whether this is a good idea can be argued and it depends (e.g. you no longer have the information in version control that says which Gradle version should be used to build your project at this point in time). This is a question every organization has to answer for itself. But people were asking for this multiple times. Excellent stuff, Adam. Hans -- Hans Dockter Founder, Gradle http://www.gradle.org, http://twitter.com/gradleware CEO, Gradleware - Gradle Training, Support, Consulting http://www.gradleware.com > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com >
