Joerg Hohwiller wrote:
Hi everybody,
I just committed a new pkg-maven-plugin to sandbox.
Just for those who are interested in what is going on here:
This code is only target to merge some ideas into unix-maven-plugin.
It will be deleted after that.
I had a chat with Trygve about working together on unix-maven-plugin.
So I added my pkg-maven-plugin to sandbox so Trygve (and whoever) may
have a look if there is something useful inside for unix-maven-plugin.
@Trygve:
I am going to continue our discussion here so everybody who
is interested can potentially join in.
1. About the name. I totally agree with you. pkg-maven-plugin
is not a good name. And since package*/deploy*/install* are
all terms already in use by maven, we should avoid such names.
unix-maven-plugin is just fine.
Cool. I don't mind picking up the discussion once it's closer to a 1.0
release.
2. Pure Java implementations of packagings:
Awesome that you already made such progress.
We should see, how we can bring this together but
it is really cool if you can build e.g. debian packages
everywhere without having fakeroot and dpkg available.
We will see how far we'll get here. I dont feel like
reverse-engineering Sun's pkg format but maybe we can
just benefit from others that already did this before.
The .deb format is easy and I've already implemented the Ar format which
was required in addition to tar. It is just a matter of switching to it
and see if the ITs pass.
3. Ideas: I just checked out your code but have NOT really
got into yet. I will do that the next days.
But what was important to me is:
* let common things (file permission and ownership,
dependencies to required packages [not maven-dependencies],
general info metadata, etc.) be configured in a general
way that does NOT depend on the actual target package
format (deb, pkg, yum, rpm, ...).
File attributes (owner, group and permissions) is already a common
object. So if FileMode and RelativePath.
* allow the user to override these common settings
for a specific format (e.g. for a debian-package the
dependency shall be named different than a suse-rpm).
This may even go down to OS (ubuntu also uses deb but
dependencies might differ slightly in some case).
I would also offer the possibility to generate
RPM-Specs or Debian-Control files directly via
maven-resources and filtering.
I haven't looked at dependency generation at all. Not sure how that
would work, people seem to have wildly different ideas here.
So in such case the generated resource overrides
other settings. If no such resource is available,
such files are generated directly (from unix-maven-plugin).
This allows ultimate flexibility for very
specific usecases that we maybe do NOT want to
cover individually.
Two thinks you should look at in my simple
pkg-maven-plugin and where unix-maven-plugin
could benefit from are:
- - powerful and flexible unix-like definition of
permission and ownerships
Check out the integration test to see how I set attributes on file objects.
- - plugin concept within the plugin. This allows
end-users to extend existing packagings or even
add new ones without hitting the code of the actual
maven-plugin itself (Haven't compared to your code).
Currently it should be possible to add your own "assembly operations"
which give you the ability to change the generated file system as a part
of the assembly phase.
So I hope we have some good starting point
for discussions and further ideas.
It would be awesome if we would bring all our
ideas and experience together into unix-maven-plugin.
Looks good. I'm currently working on getting the 1.0-alpha-4 release out
but hope that it should be done before I leave for JavaOne on Friday.
Be sure that I will NOT commit any change to your
code without asking. I might start with some patch
and then we will see how it turns out.
I don't mind if you commit stuff as long as the tests pass, just know
that I might go over it to make sure it is consistent with the current
design ideas and make sure that the integration tests pass.
--
Trygve
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
