On 19/02/2013, at 6: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.
I'm not seeing what understands how to convert it into a Java* component into a
file tree type thing for a distribution (e.g. put the jar and deps in /lib).
> 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.
How general is “application” here? If it's “all types of application” then I
think it's too general to be useful. If we focus on something like “java
application” then I think #2 makes the most sense. The “application” is the
higher level construct that describes things like script names, libs etc. The
distribution is not much more than a named file tree.
I'm not sure there's a common “application” abstraction to be found.
> 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
I'm not sure a command line application knows anything about source sets. I
think it's a composite of one or more components.
I don't quite see command line application == a type of component. As far as
the app is concerned, I'm not sure there's much of a distinction between what
was built and what was a “dependency”.
> - 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.
That's interesting. I saw it a little different before, but I can see the logic
in the “application” not being a physical manifestation at all. So
distributions start to look like more structured, focussed, recipes for the
eventual file tree…
So: components (what's the code) → application description (e.g. main class,
JVM settings) → distribution (spec for the physical manifestation in domain
terms) → files
> - 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.
Are you saying this would be necessary? Or just possible if you happen to want
to a composite 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.
That seems a solid basis to go forward with. I don't really see any questions
in there to be resolved at this point.
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
