-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Trygve,
thanks for your reply. Now worries for the delay.
Usually I am the one who gets lost for a long time...
>>> 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.
I still do not see the real bugs that are left in
resource-plugin and dependency-plugin.
Both have made great progress and I am really happy with them...
But yes, some of the fixes took ages in the last 2 years,
especially for resource-plugin.
>
> Speed is an important aspect when you're trying to assemble enough of
> these packages.
OK. Point for you.
>
>> 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.
OK, but "just" a performance issue.
>
>>> 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)
dependency-plugin can handle this as well.
For resources there is typically no such need,
because you have them under your control.
>
>>> 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?
Typically you will have defaults for file permission and ownership.
I also added support to have rules via patterns (glob or regexp).
So I can do chmod a+x on **/*.sh, etc.
In such case I will typically have no additional config.
>
>>> 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.
What lots of xml? Did you look at my example. I guess you will
need more XML to do the same thing with you plugin.
>
>>> 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.
I want to draw a conclusion:
You have already implemented cool features and those have
better performance that I belief without measuring.
My goal is NOT to convince you to give this up and kick it out.
What do you think of bringing both approaches together.
You will simply add everything in ${project.outputDirectory)
to the package as well. In you current use-case that directory
will be empty and nothing changes so far. However users that
are familiar with common maven features and plugins can
generate file to ${project.outputDirectory) and are also happy.
Further you can also mix both ways.
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.
What do you think?
>
> --
> Trygve
Regards
Jörg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkpNE2cACgkQmPuec2Dcv/+HFQCfTZN8/MaqAF5RaVQ13Sk2XHHB
T3YAn2I+4VaEihWqc9vGpX6m4LmXTUhr
=NMZ4
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
