I have updated http://wiki.gradle.org/display/GRADLE/Plugins as suggested. I have also updated the instructions to hopefully be clearer and added a basic example project.
For now the example assumes the user has a repository with the compiled plugin somewhere. Is there a preferred location for these? kind regards, Sebastian On 26 Sep 2011, at 21:07, Sebastian Gozin wrote: > 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 >> >
