On 17/01/2013, at 10:11 PM, Luke Daley wrote: > > On 17/01/2013, at 11:03 AM, Luke Daley <[email protected]> wrote: > >> >> On 16/01/2013, at 8:37 PM, Adam Murdoch <[email protected]> wrote: >> >>> >>> On 17/01/2013, at 3:45 AM, Luke Daley wrote: >>> >>>> >>>> >>>> On 16/01/2013, at 6: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 don't fully understand the scope of what this thing is. >>>> >>>> Is it anything that can be produced during a build? Or is it something >>>> that is produced as a kind of primary goal? >>> >>> The scope is pretty broad: Pretty much any thing that can be used during a >>> build. This includes the things that are produced as a primary output and >>> the things that are intermediate. It also include the things consumed by a >>> build. >>> >>> The idea is to come up with an analog for 'task', but for things rather >>> than for actions. These things will have identity and be strongly typed. >>> They will be wired together in a dependency graph. They represent the >>> physical thing + meta-data about the thing. Some of these things will be >>> buildable, some will not. And some will sometimes be buildable and >>> sometimes not. >> >> Really, these things are just artifacts… in the general sense, not in the >> way we use it now. Dependency management is just about declaring/managing >> these things that you get from some body else. >> >> For me, “artifact” is the right term. But, it may carry too much baggage. I >> think it warrants serious thought though. My gut feel is that we can reclaim >> this term, and that it's the right one. > > I missed that there was an earlier discussion on “artifact” that ruled it > out. Disregard the above.
It wasn't necessarily ruled in or out. My point was just that the term 'artefact' doesn't quite imply the right stuff. But that's probably going to be true of any term we use. Maybe we can reclaim 'artefact', as you say. We'd have to come up with another term for the things we currently call 'artefacts'. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
