I've finally re-read this thread with the appropriate brain-cycles available to really grok it. Sorry it's taken me so long, I'm a little slow... This reply is really just paraphrasing to clarify to me (and maybe others) the direction we're heading.
I really like the underlying concept here: that a build will describe more of "what" we're trying to build, rather than focussing on "how" it gets built. So instead of configuring a JavaCompile *task* with the 'targetCompatibility' we'll be configuring the *jvm library* (or perhaps the classes packaging) that we're trying to build. Of course, we still need ways to describe *how* to build something, but it seems like these are more likely to be standard and rule-based. We'll have a bunch of plugins that add rules that configure the chain of how something is built from it's inputs. On 24 January 2013 13:29, Adam Murdoch <[email protected]> wrote: > > There are a bunch of interesting things we could do with this. One that > might not be apparent is that we can short-circuit building the tasks for > inputs that could exist, but don't. For example, if a Java source set is > empty and has no inputs, then we don't need to create a compilation task > for that source set. So, for a Java project that contains only tests, the > the `compileJava` and `processResources` tasks would not be created. This > can happen transitively as well. So, if a Java source set is empty, and it > has an ANTRL source set as input which is also empty, then we don't need to > create either the 'generateParser' or 'compileJava' tasks. > > A similar approach could be taken with the build item graph, too. If the > java plugin were to state 'this project may produce a java library called > main' instead of 'does produce', then the main jar -> main classes -> main > source set graph is not required if there is no main source set. > > What this means is more flexible convention plugins: 'this project may > produce a java library, and it may have unit tests' is a more flexible > convention than 'this project does produce a java library and it does have > unit tests'. > > It also means fewer tasks need to be created, configured and executed, > which means faster builds and also removes some noise from the logging > output. > > - Each of the JVM -language plugins add rules that can compile the > language source that forms inputs to a JVM packaging. And that can generate > the API docs from the language source that forms inputs to an API > documentation packaging. > - Each of the native -language plugins add rules that can compile the > language source that forms inputs to a native packaging. > - The antlr-language plugin adds rules that can generate source from ANTLR > source sets that form inputs to a language source set. > - An opinionated 'jvm-library' plugin states that for each JVM library > component 'n', there is a jar packaging 'n', which has an input classes > packaging 'n', which has as input a production source set 'n', which > includes a source set for each supported JVM language. > - This plugin may defer adding the language source set until it is either > referenced (to be configured) or the conventional source dir is not empty. > - This would mean, in turn, that we wouldn't add compile tasks for > languages that are not required to build the classes packaging. > - An opinionated 'jvm-unit-tests' plugin that states that each project has > a single 'test' classes packaging, which has as input a test source set > 'test', which includes a source set for each supported JVM language. Plus > adds the appropriate test task. > - The java plugin applies the the java-language, jvm-library and > unit-tests plugins, and defines a single 'main' JVM library. > - Similarly, an opinionated 'native-component' plugin states that for each > native component 'n', there is a binary packaging 'n', which as as input > object file packaging 'n', which has as input a production source set 'n', > which includes a source set of each supported native language. > - An opinionated 'native-unit-tests' plugin, does the same kind of thing > as the 'jvm-unit-tests' plugin. > - The cpp-lib and cpp-exe plugins apply the cpp-language, native-component > and native-unit-tests plugins and define a 'main' library or executable. > > In other words: > > - The 'capability' plugins add classes of things, and rules to build a > thing from its input things. > - The 'opinionated' plugins that add instances of things, and rules that > state what a given thing's inputs are. > It's almost clearer if we refer to 3 types of plugins: 1. 'capability' plugins as you described 2. 'convention' plugins that, given an instance of a component, define the various build-items and their relationships (eg your 'jvm-library' plugin, above). 3. 'opinionated' plugins that apply some of 1&2, and define one or more components to build. > We might offer some way to back chain from a given build item, and infer > its transitive inputs, similar to make. So, if I say 'there is a java > library component called main', we might have some rules that say: > - A java library 'n' can be packaged as a jar binary called 'n'. > - A jar binary called 'n' can be built from a class directory binary > called 'n' > - A class directory binary called 'n' can be built from a source set > called 'n'. > - A source set called 'n' includes java source from 'src/n/java'. > > So, we can work backwards through these rules, and infer from the presence > Java source files in 'src/main/java' how to build a java library called > 'main'. There's still a graph of build items here, so that the java source > set is a transitive input into the final binary. > > Our conventions might just be a set of these kinds of rules, and the > statement 'this project produces a java library called main'. > > So we're taking this idea further. Instead of saying that we have rules for "how something *is* built from it's inputs", the rules turn into "how something *can be* built from all of it's *possible* inputs". This permits us to only wire up the tasks that are required based on the presence of the inputs. Am I on track with this summary? Not sure I have any constructive input to make at this time, but it's been helpful to me to distill the discussion, and hopefully it's helpful to somebody else as well. cheers Daz
