Joerg Hohwiller wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Trygve, hi everybody,
I started to get into unix-maven-plugin.
So far I like the general configuration of
common package meta-data and your excellent
documentation how this is mapped down according
to the actual format.
However currently the site has various dead links:
http://mojo.codehaus.org/unix/unix-maven-plugin/usage.html
http://mojo.codehaus.org/unix/unix-handbook/handbook
http://mojo.codehaus.org/unix/unix-maven-plugin/unix-maven-plugin/plugin-info.html
http://mojo.codehaus.org/unix/unix-maven-plugin/developers/
Those are broken if you go through other modules that the front page.
I'm not sure how to fix that, any help/hints from a Maven Site guru
would be very much appreciated.
For the meta-data I would like to work on
adding dependencies. Here I am NOT talking
about maven deps but about dependencies of
the generated package.
That would be great. I would be nice if you could create a note on what
kind of data you would like and how it would map in the different formats.
I would also like to add the ability to state extra dependencies (IOW,
manual dependencies) in each of the formats in their format extension
parts (<rpm>, <dpkg> etc).
Further what I want to understand is, why you added
all this <copyArtifact> and <extractArtifact>
in <assembly>?
We already had the "re-invent-the-wheel" discussion
about things like this when talking about the
philosophy of solaris-maven-plugin.
I mean there is maven-dependency-plugin,
maven-resource-plugin and filtering
and all what maven already offers.
Why not just let the user build the package
content with all features of maven
to build.outputDirectory and then build
a package from that. Sure you will still
need support for symlinks and permissions.
What was your motivation to go a different way?
Or am I just missing something?
Mainly because those utils one or more of 1) buggy, 2) slow, 3)
incomplete and 4) not sufficient.
You didn't mention the assembly plugin but that also falls into that list.
I know we had the discussion about not reinventing the wheel, which I
still stand by but I've come to the conclusion that this is not
reinventing the wheel and that it was required.
Features that I can support that the other plugins can't support:
o Streaming of data directly from inside a file in the repository.
I can pick out a file from inside another JAR directly from the
artifact. This saves a copy to the local directory, another full copy of
the extracted artifact.
o Uniform renaming of files
o File attributes like owner, group owner and permissions. In addition
there are the package format specific attributes like %doc and %config
for RPM and "request", "space" for pkg.
It would be possible to use the other plugins that you mention to do one
half of the work, but then the plugin would have to do the other half of
work through a similar mechanism to what I do today.
That is where I started and was what I implemented. Once I implemented a
"set attributes"-like thing and created a good model of a file system,
adding the rest of the features was easy.
It has even spun of a whole new set of operations that I want to
implement, in addition to document how to create your own operations.
For example:
o <touch> for creating empty files.
o <echo> for creating files with hardcoded content from the pom.xml.
Hard coded means from when the plugin run so you can use expressions
there. Think "${version}".
There are more example, but I don't have my notebook here.
Did you have a look at pkg-maven-plugin.
It is just raw minimum but it should just
show how simple you can make maven to
build packages with all your custom needs.
Should I also add an example project
or is it self-explanatory.
I haven't done an in-depth look yet, but from the browse I've given it
from subversion it seems do to about the same things that I do. I think
an example pom would be useful to see how it is actually used.
I see that there isn't much code there which definitely is a positive
attribute. I realize that my plugin is quite huge in number of lines
(and number of modules) but I think the relevant parts of the plugin is
quite small.
I'm looking forward to the example pom, it seems that you have some
smart ideas on how to set/change the file attributes there.
--
Trygve
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
