On 17/01/2013, at 10:03 PM, Luke Daley 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. > >>>> 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'). >>> >>> What's the point of this term? How will it be used? >>> >>> It seems to me that this is just describing a particular physical structure >>> of a logical component. If that's the case, I think something like >>> "format", "packaging", "structure" etc. >> >> The term will be used to describe a specialisation of packaging, to describe >> a packaging that can run on the jvm. We need it for type names for the >> concrete packagings, e.g. ClassDirectory${Term} and Jar${Term}. We probably >> also want it for a type that describes these things slightly more abstractly >> for inclusion in classpaths. > > The key characteristic seems to be that it is something that is some kind of > indivisible JVM runtime… thing… e.g. classpath entry. So, what is a good name > that describes what can be an entry on a classpath? Or more importantly, some > indivisible aspect of a classpath? > > Not finding the words for this one. I'll keep trying. > >>> The term "jvm build item" seems far too general. >>> >>>> 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'. >>>> >>>> 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'. >>> >>> Do we need this distinction? Can't there just be source sets and composite >>> source sets? >> >> Possibly. Certainly this is an option for the type names we use. However, >> the "functional source sets" are a little more specialised - they represent >> a grouping of code that provides some logical function, whereas the other >> "source sets" are really just a collection source in one or more languages. >> So, a "functional source set" is-a "source set", but not the other way >> around. > > I think it might be a step to far to say that they provide a “logical > function”. I might need to define these things for reasons other than their > eventual function. I might need to compile different parts of what will > ultimately be the “main” in different ways. It's the conventions we lay on > top that impose what the function is. > > We might be better off leaving this as “source set” and differentiate it by > having a name for the language specific aspect. So, a “source set” has one or > more “language source set” components.
Lets go with that. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
