On Wed, Jan 16, 2013 at 7:06 AM, Adam Murdoch <[email protected]>wrote:
> Hi, > > To better support building Android apps (and other things), we want to > rework the jvm language plugins so that they can handle building multiple > outputs from a given set of source files. > > I've made a bit of a start on a spec here, but's pretty rough: > https://github.com/gradle/gradle/blob/master/design-docs/building-multiple-outputs-from-jvm-languages.md > > I need some suggestions for terminology: > > 1. A term for the things that Gradle builds. With this work, plus > publications, components, reports and distributions work that is happening, > we're starting to model more of the things that Gradle can build. It feels > like we should have a term for this. So far we've been calling these things > 'things' and sometimes 'outputs'. I kind of like the term 'build item' from > abuild. > I like build item. It distinguishes itself from build output, which includes the build items but also describe all transient or intermediate output that is not supposed to be consumed somewhere. Initially I thought why not use the term packaging here but I think it has too many connotations and as you pointed out suggest that it is a logical thing and not just a physical thing. > > 2. A term for a thing that runs on a JVM. This is the focus of the spec > above. The spec calls these things a 'packaging', but this doesn't really > work that well. Note that this isn't the logical thing - we're calling them > 'components' - but the physical thing. Initially, there are 2 types of this > thing - a class directory packaging and a JAR packaging. If we come up with > a good term for 'things' in #1 above, we could just shove 'jvm' in front of > it as a name for these things (e.g. 'jvm build item'). > I think jvm build item is great. > > 3. A term for a set of source of a specific language, that forms the input > to a compilation step. This is different to what we call 'source set' at > the moment - that's a logical grouping of source. The spec calls these > things a 'language source set'. > We could continue to call is source set within the new model even though it means something different there. It is kind of awkward to talk about a java language source set vs. a java source set. The problem I guess is that we have a new abstraction we also call source set with the functional source set. You wouldn't want to say a functional test source set. If people abbreviate it might create confusion, e.g. java source set vs. test source set where source set means something different. > > 4. A term for a logical set of source. Currently we call these a 'source > set'. The spec calls these things a 'functional source set'. > What about source set bundle? Than you could say that the production bundle contains the three java source sets, vs. the functional production source set contains the three java language source sets. Hans > Suggestions? > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > >
