Joerg Hohwiller wrote:
Hi there,
[cut.]
That was one of the first things I wanted to implement in the plugin but
I've done many rounds of design on it and it is finally done:
To summarize:
src/main/unix/files goes in all packages, all formats
src/main/unix/files-rpm goes in all packages, "rpm" format only
src/main/unix/files-a goes in package "a", all formats
src/main/unix/files-b goes in package "b", all formats
src/main/unix/files-b-rpm goes in package "b", "rpm" format only
In addition to these directories it will suck in the files from
target/unix/files and the similar permutations (IIRC)
"In addition" means that stuff under src/main/unix will not
be processed by resources-plugin but directly go into the
package without filtering?
But to have filtering I would
just add my stuff to src/main/resources/files
and configure filtering and output directory as
target/unix?
Great. Seems as if I am convinced now.
Sorry for the long way ;)
It probably should be filtered. Filtering is something I also have on my
TODO list, but I'm not sure how to do it or to what extent to do it.
Ideas are welcome.
The only thing left might be to think over
the permission stuff.
You already have <set-attributes>.
But if I get it right, you have to
specify entire directories (no glob- or
regexp-patterns to select files and folders
of the virtual fs) and entire mode-masks (no
chmod-like a+x g-r).
Maybe here some inspiration from my approach
could help to improve.
It support includes/excludes.
On setting the whole pattern that is the only thing that made sense for
all the other operations as they create the file at the same time (so
there are no existing modes to modify).
However, as you note that is not the case for set attributes. Actually
it is not a case for the other operations either as they should be based
on the default values.
I will definitely add support for modifying only parts of the mode bits.
One more question:
To build different formats from the same module,
I would have to change the packaging
in pom.xml, right?
I used a virtual packaging "pkg" and
configured the actual packaging as plugin
config. This allows to build different
formats using -D options.
Anyways its just fine if it is
a strict packaging...
That really violate how Maven is supposed to work, and you will probably
get an exception if you only have attached files to install. I remember
getting some exceptions on that at one time.
What I've done in those cases it so create a "unix-zip" as the primary
artifact and use the other goals (package-{rpm,deb,sysv-pkg}-attached)
to create the specific packages.
Right now each of those goals has to be configured in a profile if you
want to create a very generic pom that will build on as many platforms
as possible, but I might add a flag to automatically skip formats that
are not supported.
http://jira.codehaus.org/browse/MUNIX-19
This is very similar to the script mechanism.
Please note that using existing plugins will offer you features
that you have not implemented and some of which you will never
implement. There is ultimate flexibility then.
Definitely and I've never meant to say otherwise. I just want to make
the plugin easy to use for most cases when only simple assembly is required.
Just perfect. I will stop begging you with the
reinvent-the-wheel topic. And rather focus on
how I can add new value to your existing work.
Excellent! :)
I'm looking forward to it.
For package-dependencies my thoughts are currently:
1. Avoid the term dependency/-cies because
it might cause confusion with maven and other things.
My suggestion is to call it "relationships"
which is also the super-term used in debian and rpm
for all this kind of stuff:
http://www.debian.org/doc/debian-policy/ch-relationships.html
http://www.rpm.org/max-rpm/s1-rpm-depend-manual-dependencies.html
That's a good point, I'll rename what I'm working on now.
2. Ability to configure such relation(ship)s.
2.a. Explicitly structure them as list rather than
comma-separated string.
2.b. Separate package-name and version(range) as
debian control and rpm spec use different
syntax. For ultra specific variants we may
NOT want to handle, people can still write
everything in one string and omit version.
2.c. Define abstract normalized types of
relationships and specify how they map in
specific formats.
I am not ready with this, but my mind is
already quite clear.
To give you an idea here is some example:
<relationships>
<relationship>
<name>libc6</name>
<!-- optional -->
<version>>=2.2.1</version>
<type>required</type>
</relationship>
</relationships>
this could mean the following:
[Debian]
Pre-Depends: libc6 (>=2.2.1)
[RPM]
requires: libc6 >=2.2.1
[ZIP/TAR/...]
(nothing)
I've started to work on a very manual dep^H^H^H relationship mechanism
right now which will be just a simple list of dependencies that you can
specify in <deb>. A manual way to control the dependecies will most
likely always be required so I'll start there so satisfy some customers.
One issue I can't really figure out is the very different naming all the
distributions use for the different packages, even core packages. RPM
also can specify a dependency on files (like "/bin/sh has to be
present"). Your thoughs on this would be nice.
Does everyone agree that
RPM-requires is equivalent
to Debian-Pre-Depends rather
than Debian-Depends?
I'm not sure about that exact example, but there probably isn't much
harm in defining them as such from what I can read on the different
definitions.
--
Trygve
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
