On 28/01/2013, at 11:44 AM, Daz DeBoer wrote: > 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.
Right. Now all we have to do is make it simple, fast, and backwards compatible. :) > > 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? Yes. My thought is that there are 2 groups of rules here: One group of rules that figure out which things exist and what their inputs are, so that we can build the graph of actual things, and rules that take the graph of things and figure out the tasks that are needed to build each thing. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
