-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Trygve,
first of all thanks for your feedback. Comments go below... >> Hi everybody, > [cut.] > The last time I looked at the RPM plugin it was duplicating a whole lot > of the assembly plugin and I wasn't able to get it to work properly. Okay. So not too much to expect from there... > >> The Mojo DEB Plugin was written by Trygve Laugstol. >> >> I do not know if these guys just dumped the plugins to MOJO or if they >> are >> active community members. >> Anyways everybody interested in this toppic is welcome to get into >> discussion. >> >> Here are some openers to think about: >> - -Should the package-format be the packaging declared in the POM or >> should it >> more likely be the name of the plugins goal? > > I often tend to have separate projects that creates the .pkg so it might > be useful for a Solaris plugin to define a packaging, but at the same > time it should be possible to create a pkg from any project. Much like > the assembly plugin which can drive the build by executing another phase > and/or be a part of a build. That sounds like a good idea... > For what you are saying below, I am not sure if we both talk and think about the same requirements for a plugin to create deployment packages... >> - -Should there be a Parent-POM that all packaging modules should >> derive from? >> This could override various defaults of the Super-POM that does not >> apply in >> this case and especially could establish senseful defaults for the >> packaging module. > > Not really relevant, I don't see what they would share yet. * The output directory should be changed from "classes" to e.g. "package". * We are missing a resource directory that is filtered. But maybe this is NOT the major thing. An archetype might be better for this... > >> - -Should we create an abstract Mojo that all deployment package >> plugins should >> derive from? This could contain some common logic. > > Not really relevant either, but it should probably not be an abstract > Mojo but rather a Plexus component that the mojos could use as they see > fit. Well that should be something worth to think about... > > What I'm missing here is an overview over what these plugin can share? That is a very good point to keep focus in the discussion. Here are some ideas from me: - -There are defaults for user, group, file- and directory-permissions for the files installed on the target machine. There should be configuration properties for this. All such plugins should hopefully use the same names for those properties. - -There should be a way to configure permissions/ownership for specific files. These would override the defaults described above. It would be awesome if all such plugins would support this in the same way. (e.g. a list of entries like "/usr root:system 733"). - -All deployment packagings support metadata with at least a name, description, version and a list of dependencies. I do not know if it is a good idea to bring these things together. For my plugin I simply used a text-file with variables placed in a filtered resources directory. This is pretty easy and gives great flexibility. - -Further there are many common tasks to create the stuff that should go into the package. This can happen with plugins that already exist. > So far I've written the deb plugin and I've made some hacks at work to > build pkgs but I'm not sure what they would share. The assembly plugin > is doing all the heavy lifting as it's doing all the copying and so on Have you looked at my solaris plugin example? I do NOT use assembly, because I did NOT find it suiteable for my needs but maybe I was missing something. But I did not reinvent the wheel, too. I use the resources plugin and the dependency plugin to build the complete structure of the package into target/package/ROOT/ all with existing maven stuff. So in src/main/resources/ROOT/usr/foo/... you dump everything you want to have included as is. Then (in my case) there is src/main/templates/ROOT/usr/foo/... for all filtered resources and via the dependency plugin you can copy all reuqired jars to target/package/ROOT/usr/foo/lib/ or extract a war file to target/package/ROOT/usr/foo/webapps/ But this is exactly the thing to clarify. How does this work with the assembly plugin instead? Something that all these plugins should share in the end is a common part of the documentation describing how to produce the stuff into the "target" folder and some good examples. > and the deb and pkg plugins are only running dpkg/pkgmk. One thing I'm > missing in my pkg stuff is a plugin that creates a prototype file, today > I have an awk script that does that. When you talk of a "protoype file" you mean for solaris? I used to call pkgproto for that. Anyways it would be easy to write this logic in java. > > -- > Trygve Best regards Jörg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGGsBGmPuec2Dcv/8RAhi8AKCMEl/RTCU5VUUMWia/8RlmkvXTCwCgjPEO 8qry6+VE0O2bSiibCz+K0zI= =sTLw -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
