Joerg Hohwiller wrote:
> 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.
The bugs comment was a general comment.
>> 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.
No it can't.
This is from the Jetty integration test:
<extractArtifact>
<artifact>org.mortbay.jetty:jetty-assembly:zip</artifact>
<to>/opt/jetty</to>
<includes>
<include>**/bin/*</include>
</includes>
<pattern>/jetty-7.0.0pre3/bin/(.*)</pattern>
<replacement>bin/$1</replacement>
<fileAttributes>
<mode>0755</mode>
</fileAttributes>
</extractArtifact>
This will pick out all the files under **/bin/* and rename them to
/opt/jetty/bin/$1
>>>> 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.
I'm not comparing the amount of config required for unix-m-p compared to
pkg-m-u, I'm comparing to the typical use you have with the solaris-m-p
(which is what a lot of my projects use. For example; copying a single file:
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>unpack</id>
<phase>generate-sources</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>no.java.portal.solaris</groupId>
<artifactId>solaris-pkg-support</artifactId>
<outputDirectory>${project.build.directory}/solaris-pkg-support</outputDirectory>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
That's a lot of configuration. And you still need to configure the
permissions.
And the next chunk is as bit which involves the assembly plugin in
*addition* to its assembly.xml.
>>>> 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.
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)
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.
--
Trygve
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
