On Tue, Feb 19, 2013 at 7:33 AM, Adam Murdoch
<[email protected]>wrote:
> Hi,
>
> Thanks to Sébastien, we now have a nice distribution plugin, which allows
> you to define one or more distributions that your project produces, and the
> plugin takes care of building ZIP, TAR and install tasks for these
> distributions. Via the `java-library-distribution` plugin, it is easy to
> build a distribution for a java library.
>
> I'd like to look ahead at where we might go next with the
> distribution/application/java library domain.
>
> I think it would be good to use the same pattern for defining a
> distribution, that we use to define a publication. To me, it's a very
> similar problem, where we assemble something from one or more inputs. So,
> at the moment, you define a publication, add a component to it, and the
> appropriate artefacts and meta-data are included in the publication:
>
> publications {
> ivy(IvyPublication) {
> from components.java
> }
> }
>
> This would mean, to define a distribution, you would do something like:
>
> distributions {
> main {
> from components.java
> }
> }
>
> I imagine the set of things you can add to a publication will be different
> to the set of things you can add to a distribution. To add something to a
> publication, it must be able to be converted to a set of artefacts +
> meta-data. To add something to a distribution, it must be able to be
> converted to a file tree.
>
> One issue to sort out is the relationship between a command-line
> application and a distribution. To make an application usable, it needs to
> be installed. To publish an application, it needs to be bundled up in a ZIP
> or TAR or rpm or installer or whatever. This is the same as a distribution.
> I think there are a few ways to view this:
>
> 1. An application and a distribution are both something that can be
> converted to an install image (a file tree or copy spec or whatever), and
> we'd add some general capability to bundle up or install or publish
> something that can be converted to an install image.
> 2. An application always has an associated distribution, and the
> distribution is the thing for which all the various bundles and that can be
> installed and published. That is, the application is the logical definition
> of the thing, and the distribution is a physical representation of the
> thing.
> 3. An application can be added to a distribution, and the distribution is
> the thing for which all the stuff can be build and published. If the
> application is not added to a distribution, it can't really be used.
>
> We would probably use the same pattern for jvm libraries, native libraries
> and native executables.
>
> I think what we're aiming for is (again) a graph of things, where a thing
> can be packaged as one or more other things, which in turn may be packaged
> as other things:
>
> - I have a command-line jvm application called 'my-app'
> - It has main class 'foo' and is built from these source sets and has
> these runtime dependencies
> - A command-line jvm application can be packaged as a launcher script
> distribution.
> - A command-line jvm application can also be packaged as other things - as
> an rpm or a native executable or an executable jar.
> - A launcher script distribution can in turn be packaged as an install
> directory or a ZIP or a TAR file.
> - A launcher script distribution can be added to other distributions.
> - A command-line jvm application can be added to a distribution, by adding
> the application's launcher script distribution.
> - A launcher script distribution can be published, by including the
> distribution's ZIP and TAR files as artefacts.
> - A command-line jvm application can be published, by publishing the
> launcher script distribution.
>
> Most things are composite, that they accept multiple inputs of various
> kinds: You can add multiple source sets or jvm binaries to a command-line
> jvm application, you can add multiple applications or libraries to a
> distribution, and so on.
>
This is great stuff. We have come along way from when we first started to
think about how the primary archive handling should move from task to
domain object level.
Hans
--
Hans Dockter
Founder, Gradle
http://www.gradle.org, http://twitter.com/gradleware
CEO, Gradleware - Gradle Training, Support, Consulting
http://www.gradleware.com
