Robert, Evgeny, I'm shared about yours comments.

When Rex contacted me first I didn't see MCLIRR-33 as incompatible with the 
plugin usage.

I'm the first on to not like when a plugin does too many things.
But like Rex explained it for me it was an improvement over options failOnError 
and failOnWarning we have in the check mojo.

If a project follow the MAJOR.MINOR.BUGFIX pattern for versions (I'm not sure 
it was really created by Apache) thus it can be easier to have an automatic 
setting of these options based on the version you are developing instead of 
changing them each time.
For a MAJOR version we accept every changes (INFO, WARN, ERROR)
For a MINOR version we accept only INFO and WARNS
For a BUGFIX version we accept INFO changes.

I'm not actively working on this plugin thus I let you the final decision, but 
myself I didn't find it useless or inappropriate

Cheers

Arnaud


On Jul 11, 2010, at 6:39 PM, Evgeny Mandrikov wrote:

> Yes - the same feeling.
> Clirr plugin is responsible for compare binaries or sources for
> compatibility and not for checking versions.
> 
> Rex, you can extend maven-enforcer-plugin by creation of custom rule:
> http://maven.apache.org/enforcer/enforcer-api/writing-a-custom-rule.html
> 
> On Sun, Jul 11, 2010 at 8:32 PM, Robert Scholte <[email protected]> 
> wrote:
>> I think I have to agree with Evgeny.
>> This type of functionality belongs to the versions-maven-plugin or
>> maven-enforcer-plugin, if it's not already there.
>> Also, the sources of ApacheVersionNumber looks like duplicate code, similar
>> code is already available in the Maven distribution.
>> 
>> - Robert
>> 
>> ________________________________
>> Date: Sun, 11 Jul 2010 03:11:10 -0700
>> From: [email protected]
>> To: [email protected]
>> Subject: Re: [mojo-dev] Hi all! Just tossed three patches at the clirr mojo
>> 
>> May I ask why?
>> It seemed like a very natural fit to me. A tool like clirr seemed as it were
>> built to help enforce version standards.
>> Why not have it be explicit?
>> Rex
>> 
>> On Sun, Jul 11, 2010 at 3:03 AM, Evgeny Mandrikov <[email protected]>
>> wrote:
>> 
>> Hi Rex,
>> 
>> First of all - thanks for your contribution. But I'm not sure about
>> MCLIRR-33 - I think that clirr plugin should not be used for such
>> tasks.
>> 
>> On Sun, Jul 11, 2010 at 8:14 AM, Rex Hoffman <[email protected]> wrote:
>>> First up, Thanks all for great maven plugins!!!
>>> So just lobbed 3 jiras against the clirr mojo, all with patches of course.
>>> http://jira.codehaus.org/browse/MCLIRR-31
>>> http://jira.codehaus.org/browse/MCLIRR-32
>>> http://jira.codehaus.org/browse/MCLIRR-33
>>> Site documentation fully updated.
>>> 33's patch unfortunately contains the contents of 32's as well.
>>> Did my best to minimize any potential side-effects.  Gave the code it's
>>> first test (not a very impressive one).
>>> I'd also like to write a plugin that takes the version number convergence
>>> checks that are done in by the dependency analysis report and enforce them
>>> at build time.
>>> If you'd be willing to host it here, I'd be appreciative.
>>> Rex Hoffman
>> 
>> 
>> 
>> --
>> Best regards,
>> Evgeny Mandrikov aka Godin <http://godin.net.ru>
>> http://twitter.com/_godin_
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>> 
>>    http://xircles.codehaus.org/manage_email
>> 
>> 
>> 
>> 
>> ________________________________
>> New Windows 7: Simplify what you do everyday. Find the right PC for you.
> 
> 
> 
> -- 
> Best regards,
> Evgeny Mandrikov aka Godin <http://godin.net.ru>
> http://twitter.com/_godin_
> 
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
> 
>    http://xircles.codehaus.org/manage_email
> 
> 


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply via email to