On 28/01/2013, at 5:49 AM, Adam Murdoch <[email protected]> wrote:
> > 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. :) You forgot: “and before our competitors” >> 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 > -- Luke Daley Principal Engineer, Gradleware http://gradleware.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
