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. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
