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.
>
>> 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 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.
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
