On 4 February 2013 00:07, Adam Murdoch <[email protected]> wrote:
> Hi,
>
> So, we're planning to have a bunch of 'jvm binaries' that can be built from
> various language source sets and other things. There will be a few different
> types of binaries, such as class directory binaries and jar binaries,
> possibly some others.
>
> Something we need to sort out is how to structure the DSL for these
> executable things. The current plan is to have a single container that owns
> all of these jvm binaries, so you might declare something like this:
>
> jvm {
> binaries {
> mainClasses(ClassesDirectoryBinary) {
> … some inputs and other configuration ...
> }
> mainJar(JarBinary) {
> … some inputs and other configuration …
> }
> }
> }
>
> There might be a similar container for native binaries:
>
> native {
> binaries {
> windowsX86DebugShared(SharedLibraryBinary) {
> … some inputs and other configuration …
> }
> windowsX86DebugStatic(StaticLibraryBinary) {
> ...
> }
> windowsX86DebugExe(ExecutableBinary) {
> …
> }
> }
> }
>
> Some questions:
>
> * Is using a flat name the best way to identify these things? Once you add a
> few dimensions, the names start to get awkward. This is certainly can be the
> case for native binaries, and can also be the case for jvm binaries. For
> example, I might have (feature, binary type, groovy version, jvm version) as
> relevant dimensions for a Groovy library that targets multiple groovy
> versions and jvm versions.
Are the names of these things important at all? Or in general are we
just forcing users to come up with a name that adds little value? How
often does a user need to differentiate between them by name?
We could consider a DSL similar to the repositories syntax:
jvm {
binaries {
classes {
name "main" // optional
… some inputs and other configuration ...
}
jar {
... we generate a sensible name ...
… some inputs and other configuration …
}
}
}
It's possible that we treat this as a standard pattern, whereby a
NamedDomainObjectContainer could support both with some sort of DSL
magic:
container {
name(Type) {}
subtype { // generated name }
}
Or maybe get rid of the 'name' method altogether, and go with:
// In all cases the added element must provide a unique name, which
may or may not be configured explicitly.
container {
generalType(SubType) {} // eg 'publication' for 'publications'
container, or 'dependency' for 'dependencies' container.
subType { } // eg 'ivy' for 'publications' or 'project' for
'dependencies'
}
> * What do we do with specialised types of jvm binaries, that run on the jvm
> but which require a certain runtime and that are packaged in a certain way:
> a WAR or exploded J2EE web app or an OSGi bundle or Gradle plugin?
>
> * Is the separation between jvm binaries and native binaries useful? Should
> there be a single `binaries` container? Or should it be finer-grained to
> include type, so that there is a `jvm.binaries.classes` and a
> `jvm.binaries.jar` container and a `native.binaries.staticLibs` container?
> Is the type of runtime actually less important than the type of thing, so
> that it should be `binaries.jvm` and `binaries.native`?
Where would combined-and-optimised javascript fit into this model?
What about shell-scripts that are tailored for a runtime?
Maybe we need a few more use cases to flesh out the DSL. Or would
these be declared in a different container?
>
> Very similar questions to source sets, re. how to arrange them and which
> dimension wins over the others and which need to be encoded in the name and
> which are encoded in the structure. Maybe we should rethink our container
> DSL a bit more deeply. The publications would also benefit from have a
> composite identifier (e.g. groupId, artifactId, version).
Yes I think this could benefit from a re-think - the current proposed DSL is:
publications {
myPublication(IvyPublication) {
organisation 'my-organisation'
module 'my-module'
revision '1.2'
}
}
The only thing the name "myPublication" is currently used for is
generating task names. Other than that, it adds little value. We will
be enforcing that the org:module:revision is unique, and this is
really how the publication is identified.
In that case, something like the last option above might work better:
publications {
ivy {
organisation 'my-organisation'
module 'my-module'
revision '1.2'
}
publication(MyCustomPublicationType) {
// must have a unique 'name' after applying this configuration
}
}
--
Darrell (Daz) DeBoer
Principal Engineer, Gradleware
http://www.gradleware.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
