sverhagen wrote:
Trygve Laugstøl wrote:
I'll have to take a closer look, but setting permissions will require
the plugin to do exec's to chmod which I've tried to avoid because I'd
like to do it in all Java for both portability and not least speed.
All good and well, but was it not you who wrote the following in the
plugin's handbook?
The Unix Maven Plugin is meant to fill in the gap between creating
platform independent applications and reality
If you're gonna leave it up to the maintainer scripts in the Debian package
to correct the permissions, you're not really benefiting from what dpkg can
do for you. Also, when you'd run Lintian for your Debian package, it'll
complain a lot. I've actually made piece with having to do this build on a
Linux machine. The portability of the output files that is being the future
of this plugin is much more important to me. It'll give me the confidence
that I can switch from Debian to Red Hat whenever I want.
I'm not going to leave it up to the scripts, but it is just not complete
yet. It is in alpha for a reason.
Even if I've tried to follow a pragmatic approach when writing the
plugin it has been a huge effort and there are lots of stuff to do
before it is complete.
As a matter of fact, while I'm sharing opinions anyway, I think that the
Maven assembly plugin is already doing a great job at the things you're
still only scratching the surface with. It can already prepare everything
with the right permissions etc. It'd have much more liked for the Unix
plugin to focus on the packaging, not the assembling. I.e. your plugin is
trying to do much more than just what it should be good at: packaging for
the target platforms.
Well, I don't share your opinion on the assmebly plugin. I find it very
verbose to configure (so verbose that it is hard maintaining the files),
slow and anywhere from complete. Try to move to corner cases of the
plugin and you'll find a big can of bugs.
It can not prepare stuff with permissions (no support for changing
owner/user).
A couple of major reasons for implementing parts of the assembly plugin:
1) I can stream files directly from the repository to disk. In the
future it will stream directly into the generated package if the format
support that (deb, rpm and sysv pkg does)
2) I can pick out files inside a file or an artifact in the repo
directly without going through a major XML hassle of downloading files
with the dependency plugin and using the assembly to pack stuff back up.
3) it was quite easy, commons-vfs does all the heavy lifting.
4) The integration and error messages that I can provide makes the
Unix plugin *much* easier to use than the assembly plugin
I think there still are ITs in the Solaris plugin that uses the assembly
plugin to illustrate the amount of stuff that has to be done to do
smaller stuff.
I did start using the assembly plugin and I implemented the support for
setting permissions on aseemblies with the "dir" packaging, but it was
too complicated designed that I could bother to fix all of it. Hopefully
once the features in the Unix plugin are complete the code can move back
to the assembly plugin where it could/should be.
--
Trygve
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
