Joerg Hohwiller wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi everybody,
Please add a JIRA in the at jira.codehaus.org for the mojo project in
the component plugin-submission.
Please check they enforce the mojo guidelines (defined in the mojo web
site mojo.codehaus.org)
I am not sure if you all got me right:
I wrote a simple but flexible plugin that allows to create packages for solaris.
(But yep, I would submitt it to Mojo (sandbox first of all) and be available for
maintainance)
In Mojo I found such plugins for RPM and DEB that already exist.
All of these plugins have the same goal: create a deployment package of the
outcome of a maven module. But also all of them do it completely different and
have a different philosophy.
I would love to have a discussion with the various makers of these plugins
and/or all that are interested and find a common way to solve this issue with
maven.
Creating totally different animals for the same major task seems odd to me.
I use maven in private for my open-source projects as well as for the business.
This use-case is more an enterprise need, but I have much experience in
deplyoment strategies (already solved this issue several times both with core
ANT and with Maven) and would provide my knowledge.
But before writing another RPM plugin, I would like to bring these things
together.
FYI:
The Mojo RPM Plugin was written by Bob Allison.
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.
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.
- -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.
- -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.
What I'm missing here is an overview over what these plugin can share?
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
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.
--
Trygve
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
