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.
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
