On 16/04/2013, at 9:09 PM, Luke Daley <luke.da...@gradleware.com> wrote:
> What's the current state of this? > > Are you still looking for input on what's described below? Yes. > > On 15/03/2013, at 1:38 AM, Adam Murdoch <adam.murd...@gradleware.com> wrote: > >> Hi, >> >> There's now a first cut of the new source set DSL in master. Right now, it >> pretty much just mirrors the old structure: a project has a set of >> 'functional source sets', and each functional source set has a single >> 'language source set' for each supported language. The next step is to >> introduce some flexibility in this model, so that you can use it to model >> other structures. In particular, we want to be able to group source in more >> interesting ways: >> >> - Group multiple source sets of a given language to be compiled together. >> For example, when building the 'release' variant of my Android application, >> I want to take the 'main' java source and the 'release' java source and >> compile them together as a single batch. >> - Group multiple source sets of different languages to be compiled together. >> For example, I want to take my 'main' java source and my 'main' groovy >> source and compile them together as a single (logical) batch. >> - Group multiple source sets together to form some logical thing. For >> example, I want to take my 'main' java source and 'main' resource and 'main' >> groovy source and bundle them together in a 'main' source set that I can >> pass around as a single thing and add as input to various things or publish >> or whatever. >> >> When we add a source set to a binary, we need to be able to turn it into the >> language specific views in order to compile it (or whatever it is we need to >> do with it). For example, for Java source we need to know the Java language >> level that the source conforms to and the compile dependencies that the >> source has, plus some general stuff like the character encoding that the >> source files use. >> >> Ideally, this language specific view is read-only (and even better if it is >> immutable) and somewhat more general than the view you would use to >> configure the source sets. >> >> The current plan is to have language-independent composite source sets and >> language-specific (and strongly typed) source sets. The language source sets >> are the 'atomic' groups of source, which you can combine in whichever way >> you like by creating a composite source set and adding the appropriate >> source sets to it. A composite source set would accept both language and >> composite source sets. These source sets would all be configurable. >> >> In addition to this, we would have a separate set of strongly typed >> interfaces that define the language specific stuff you need to consume the >> source. You can ask a source set to turn itself into one of these views (it >> may just return `this`). The aim here is to keep separate the consumption of >> source set from how they are defined and configured, and so allow many >> different ways that source sets can be defined and built, but a consistent >> way to plug them in as inputs to something else. >> >> Things get a bit tricky when source sets need to be combined into a single >> set, as the strategy for merging the language-specific stuff is, itself, >> language-specific. There are a few approaches we could take: >> >> 1. Composite source sets know how to combine language source sets. They >> would need help from the language specific plugins for this, possibly by a >> language plugin registering a converter of some kind. >> >> 2. Composite source sets are just dumb collections of source sets. When you >> add a composite source set to a binary, it is equivalent to adding each of >> its children separately. A language plugin may make available a language >> source set implementation that can combine other language source sets of the >> same type, and you need to wire these up yourself. >> >> 3. Composite source sets are just dumb collections of source sets as for #2, >> and all language source sets can contain other language source set of the >> same type. >> >> At this stage, I think we'll probably go with #1, as it means that the >> aggregation is completely the source set's business (though the source set >> may ask some plugins for help), and nothing to do with the consumer. >> >> Regardless, for any of these options, to add support for a new language you >> need to provide a language specific source set, plus some strategy for >> merging the language source sets, plus some rules for what to do when the >> language source sets are added to a binary. >> >> >> -- >> Adam Murdoch >> Gradle Co-founder >> http://www.gradle.org >> VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting >> http://www.gradleware.com >> >> Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: >> http://www.gradlesummit.com >> > > -- > Luke Daley > Principal Engineer, Gradleware > http://gradleware.com > > Join me at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: > http://www.gradlesummit.com > > > --------------------------------------------------------------------- > 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 Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.com
