On 02/25/2013 06:45 AM, Luke Daley wrote:
> On 22/02/2013, at 3:32 AM, Adam Murdoch <[email protected]> wrote:
>
>> 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?
> It's becoming obvious that we need to formalise the idea of “configured”. Or
> at least, formalise the notion of there being a configuration lifecycle.
> Perhaps though this is not really a separate concept. That is, building (aka
> configuring) the model is not inherently different to building files for
> example.
>
> One idea is just to go fine grained with the types and modelling. So strongly
> model the specification of source as a buildable thing and separately model
> the actual physical files, having both of these things express some kind of
> opaque dependency like Buildable. So if you just need to know when it's
> configured, you'd use the specification's buildable. It may be hard to find
> the concepts to break apart here sometimes though. So something like…
>
> class JavaSourceSet {
> SourceDirectorySetSpec getSrcDirs()
> ClasspathSpec getCompileClasspath()
> }
>
> class SourceDirectorySetSpec implements Buildable {
> SourceDirectorySet getBuilt()
> }
>
> The general idea being instead of introducing a protocol that allows us to
> depend on something in a certain state, we introduce more fine grained
> modelling.
I hope this would also include the ability for one project in a
multi-project build's configuration stage to depend on a built artifact
from another project in the multi-project build. This would make for
something a little more general than buildSrc if you wanted to do
something like create custom tasks or plugins as projects in a
multi-project build, perhaps as an intermediate step toward getting it
ready to move out into its own project.
--Jay (popping out of lurker mode for a brief moment)
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
