On 22/02/2013, at 2:10 PM, Adam Murdoch wrote:
> Hi,
>
> So we're starting to build out a graph of build items, with our source sets
> and jvm binaries (and publications). At the moment, this is pretty basic,
> where you can define some source sets and define some jvm binaries and attach
> the source sets as inputs to the binaries. Or you can attach a component as
> input to a publication.
>
> There are a few different types of build items that we need to model:
>
> 1. Something that already exists and does not need building. These things are
> only consumed in the current project. You need to be able to define it and
> configure some stuff about how to use it. For example: here is a java source
> set and it includes java source from this directory and that directory.
>
> 2. Something that is produced outside the project. Again, these things are
> only consumed in the current project. You need to be able to define a
> dependency on the thing and resolve it into something usable. For example:
> give me a jvm binary for 'org:gradle:gradle-core:1.5+' so that I can use it
> in my compile classpath, or give me the source set for project(':other') so I
> can generate some aggregate javadoc from it.
>
> 3. Something that is produced by the project. You need to be able to define
> it and configure some stuff about how to build it. For example, please
> produce a jvm binary into this classes directory, built from these input
> source sets and targeting this jvm version.
>
> 4. Something that is produced and consumed within the project. As above,
> where the configuration that describes how to build it also implies how to
> use it.
>
> 5. Something that is a view over some other things. For example, a composite
> or a filtered source set. These things are only consumed.
>
Another question is how to represent the work that need to be done to make the
build item usable. Each thing is usable in a bunch of different ways, and each
of these require different work to be done. Some of these ways of using an item
are cross-cutting, and some are type specific. Here are some examples:
* In order to refer a thing, to pass it around, I don't need to do anything
more than define it (ie here is a java source set called 'mainJava').
* In order to use a java source set's compile classpath as a set of dependency
definitions, I need to make sure the source set has been configured. This might
mean configuring the current project, which might mean running some tasks to
build some other project that is used to configure the project, which might
mean configuring that other project, and so on.
* In order to use a java source set's compile classpath as a set of files that
will be built (for example, say I'm generating a classpath manifest file), I
need to make sure the source set has been configured (as above) and I need to
resolve any dependency definitions referenced in the classpath, which might
mean configuring each project referenced by a project dependency or resolving
the meta-data for a thing from a repository. I don't need to build or download
the files themselves.
* In order to zip up a java source set's source, I need to make sure the source
set has been configured (as above), and I need to make sure the source has been
generated (if required). I don't need to do anything with the classpath.
* In order to compile a jave source set, I need to make source the source set
has been configured, the source has been generated, the compile classpath has
been resolved to files, and the classpath files built or downloaded.
In other words, Buildable isn't going to cut it. I don't think we necessarily
need to go quite as fine grained as the above, but we need something better
than 'configure and build and resolve and download all the things that might be
required to use this thing in any way'.
Suggestions?
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
