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). > >> 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”.
From the application's point of view, that's probably true. Same for building a distribution. For building an rpm or deb, the application itself would need to end up in the bundle, and its dependencies (built or external) need to end up as separate bundles and dependency declarations in the bundle's meta-data. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
