All of these sound like excellent ideas. As you suggested in your previous mail I'll compile the information on http://wiki.gradle.org/display/GRADLE/Plugins, make an example project and then look into the steps you suggested here.
Cheers, Sebastian On 25 Sep 2011, at 23:29, Adam Murdoch wrote: > > 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 >
