On 22/02/2013, at 7:53 AM, Philip Crotwell wrote: > > 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 think these are all good things to consider, also .rpm and .deb files too. The vague plan is that: * A mac app bundle would be treated similar to a launcher script distribution, so it's a way of packaging a jvm application, which in turn can be packaged as a .app directory or a zip or a .dmg file or whatever. * A .exe is a way of packaging a jvm application as a native executable, which you can then do whatever it is we allow for native executables. There would be no difference between a native executable built with launch4j or the c++ compiler, as far as what you can do with it. * An installer is a way of packaging up installable things, which would include anything that can be added to a distribution, plus some actions to execute. * izpack, .deb and .rpm would all be different types of installers. There's some cross cutting stuff here for an application (jvm based or native): * An application has a launcher. This might be a launcher script, a native executable, the os x java stub, or an executable jar. Or a groovy script or ... * An application may require some supporting files that must be present at some location relative to the install base directory (e.g. config files, runtime jars, plugins). * An application may require some supporting files that must be present at some absolute location (e.g. config files, native shared libs, other applications). * An application may require some actions to be executed before it can be used (e.g. windows registry entries). This means that not all applications can be packaged as a 'simple' distribution that is just a file tree. > > 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? Once we get further down this path, I think this would be really useful. If nothing else, we should integrate these plugins with the application/library/distribution model. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
