On 22/02/2013, at 12:01 AM, Luke Daley wrote: > > 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).
This is something we're yet to sort out for publications, too. Some rule, I imagine, will know how to take a jvm library and map it to a file tree, according to some convention. Similarly, some rule (not the same rule) will know how to take a jvm library and map it to a maven publication, and some rule will know how to map it to an ivy publication. Given that these rules are separate from the jvm library and the distribution, it should be possible to take the convention and replace it with your own. > >> 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? For this discussion, it's just shorthand for command-line jvm application. It might stretch to native command-line applications, too. > 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? Just possible. For example, if I'm building an SDK, I have a bunch of libraries and tools to bundle up into single a composite that has a separate identity. I should be able to just add these things as inputs to the distributions. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
