On 26/09/2011, at 6:20 AM, Rene Groeschke wrote: > Hi Sebastian > Am 25.09.11 15:21, schrieb Sebastian Gozin: >> In the past I have worked on a project where we would use the maven rpm >> plugin to create native packages for centos. >> Currently I am working on projects which are to be deployed on ubuntu and >> haven't had much luck finding a similar plugin for ubuntu/debian packages. >> I did find a maven plugin with limited functionality but I like gradle >> better so tried my hand at creating a plugin that can create ubuntu/debian >> packages with some nice configuration format in the build script. >> >> I mostly worked on it during my 2 week vacation in the beginning of July and >> then week-ends here and there to try it out with a project of mine. >> So I can use it to create packages with dependencies, init scripts, etc... I >> didn't bother too much with release notes support however. >> >> In essence the plugin generates some of the files and wraps the calls you >> would normally do manually as described on >> https://wiki.ubuntu.com/PackagingGuide/HandsOn >> >> For now the sources are available on my github >> (https://github.com/sgo/ubuntu-packager-plugin) with an example of the build >> script format and directory structure. >> Perhaps I should also add an example project using the plugin. > Excellent! A example Project is always nice to have. >> >> Now for my questions: >> - I don't have a lot of experience with both gradle plugins and making >> native packages so if anyone has some suggestions that would be great. >> - I haven't picked a legal license yet as I don't really know what's >> suitable for a plugin. Any ideas? > I'll try to port the griffon (http://griffon.codehaus.org) build to use your > packaging plugin and give you feedback then. Currently we use the ant rpm > task for that. As a macuser, I would like to see a task for packaging DMG. > Maybe this plugin is the right place for that kind of task.
I think a separate plugin would be better, as I might want to build a dmg but not an rpm, and vice versa. That is, we want smaller reusable plugins rather than big monolithic plugins. Instead, we should extract the stuff that is common to building a tgz/zip distribution, or an rpm, or a dmg into a shared location (probably a plugin). I would see something like this: * We extract a 'dist' plugin out of the 'application' plugin. This plugin represents a project that produces a distribution. It provides a model for defining what goes in the distribution, plus some convention for where to find some of this stuff. It also adds a 'distZip' and 'distTgz' task to build the distribution, an 'install' task to install it, and a publication to publish it. * We change the 'ubuntu' plugin to extend the 'dist' plugin, and to use the dist model to decide what to include in the rpm. * We add a 'dmg' plugin which also extends the 'dist' plugin, and uses it to decide what to include in the dmg. * We extract meta-data about the project such as the copyright, author details, homepage and so on, out of the 'ubuntu' plugin and move it somewhere shared, perhaps on the core Project itself. * We change the 'maven' plugin and ivy publication to use the metadata when generating the pom and ivy.xml. Later, we add a 'java-lib' plugin which extends both the 'java' and 'dist' plugins, to define a distribution containing a Java library. We also change the 'cpp-exe' and 'cpp-lib' to extend the 'dist' plugin, to define distributions containing a native exe or library. What we will we end up with is 2 things: a set of plugins that describe the logical contents of the distribution: a Java application, or Java library, or native application, or native library, or whatever, and a separate set of plugins that take a logical distribution and package it up into some physical bundle or bundles. Which means you will be able to mix and match whatever combination of logical distribution and packaging that you like. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
