Hi Not sure if this is relavant at this point, but some time back I needed to be able to create and distribute double clickable applications for both mac and windows and so created two plugins to help with this:
http://code.google.com/p/gradle-macappbundle/ for mac app bundles and dmg creation http://code.google.com/p/gradle-launch4j/ for .exe creation using launch4j They are currently stand-alone and it feels like they could benefit from this development, being special types of "launcher scripts". Perhaps they would be worth looking at as additional use cases. At least the mac app bundle also somewhat spans the concept of launcher script and distribution. Installers, like izpack, might also be nice to think about in the definition of a distribution type, in addition to tar and zip. I am not sure if they would be as widely useful as the library distribution ides, but is there any interest in "pulling" either of these? It seems like you are getting close to including the concept of os-specific applications in gradle and so I thought I would offer. No reason to reinvent the wheel. thanks, Philip On Thu, Feb 21, 2013 at 2:25 PM, Adam Murdoch <[email protected]>wrote: > > 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 > >
