On 17/01/2013, at 5:01 PM, Daz DeBoer wrote: > > > On 15 January 2013 23:06, 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 really don't like 'build item' as it doesn't really say anything. How about > 'build product', 'build artifact', or something more concrete. It's a shame > that "build outputs" is too overloaded. Or we could use something like > 'software product', 'software artefact'?
"build product" doesn't really work, because these things are not necessarily produced by a build. They are consumed as well. It doesn't quite capture the meaning - "product" implies some kind of action. An important aspect of these things is that they are things independent of action. "artifact" doesn't really work either, because these things may be made up of multiple files. These things also have meta-data. And the term "artefact" of implies a single file (or at a stretch a directory tree) with no meta-data. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
