« Return to Thread: unix-maven-plugin philosophy
Re: unix-maven-plugin philosophy
by Trygve Laugstøl
::
Rate this Message:
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
> -----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
« Return to Thread: unix-maven-plugin philosophy
| Free embeddable forum powered by Nabble | Forum Help |
