Joerg Hohwiller wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mainly because those utils one or more of 1) buggy, 2) slow, 3)
incomplete and 4) not sufficient.
I see that problem but do NOT agree with the general argument.
1) we are a community and progress is made
2) not very important to me
3) see 1)
1) and 3) is an issue because 1) it will take me *way* longer time to
implement the features that I want and 2) I'm not even sure that their
goals match what I want to do so it is even hard to "fix" them.
Speed is an important aspect when you're trying to assemble enough of
these packages.
4) important topic, see below
You didn't mention the assembly plugin but that also falls into that list.
jup. But it also does some reinvent the wheel already.
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.
I see, but I am not convinced.
Features that I can support that the other plugins can't support:
o Streaming of data directly from inside a file in the repository.
OK. understood.
Definite point for 2) (performance)
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.
Same as above.
Also, no other plugin support this.
o Uniform renaming of files
Are you talking about those Windows limitations?
No, I can use regular expressions to rename files, for example to remove
version strings on a file (foo-1.0.jar => foo.jar)
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.
Yep. This can not be done by other plugins and is something to be
solved by unix-maven-plugin.
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.
exactly.
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.
OK.
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.
Just add an empty file to src/main/resources.
I would still have to add xml in my pom to control the other file
attributes, and creating support for <touch> is a no-brainer, so why not
add the convenience?
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}".
Just add that as file to src/main/resources and use filtering.
You would already have this feature if you would not
have reinvented the wheel ;)
I'm not going to require users to learn another plugin and at *lots* of
xml when it can be done so much easier.
There are more example, but I don't have my notebook here.
Give me all arguments...
I've given you all my arguments, but I can summarize:
1) Existing plugins are missing required features
2) Ease of use for users
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 will add some example project to pkg-maven-plugin/src/it/example1
at the beginning of next week. This week I am quite busy (filing
all those Galileo bugs, etc.)
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.
What I checked in can only create zip and tar so far which is kind
of pointless. Anyhow tar already allows testing permissions, symlinks, etc.
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.
I simply re-implemented (the wheel) what unix/posix defines with
umaks, chmod, chown. In that point our solution fits because
here I also have a virtual FS concept but so simple that I did not mention
before.
This is in my opinion not re-invention, it is new software/features
required to implement the plugins that we work on. I have the same
concept which is very central in the assembly part and metadata file
generation (.spec, debian/control, pkginfo, prototype) of the plugin.
I argue that I'm not re-inventing the wheel, but using existing code,
just like the other plugins are using existing code. To me, reuse is as
much about reusing code as reusing the actual plugins.
--
Trygve
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
