Well, I worked on MCLIRR-33 for a few days so I feel obliged to make a final
appeal:
Based on the existing functionality of the clirr:check goal, this still
seems like a natural fit to me.
1) the check goal already can and will fail builds, just like the maven
enforcer plugin.
2) right now the clirr goal has code that already knows about version, it
looks up the latest version older than the current version being worked on
to check against if no comparisonTargets are given.
Though you have to list what should fail the build Errors and Warnings
if you are trying to make a minor release, and infos if you want a patch
level enhancement.
3) My patch simply gives a dev the ability to choose to have the clirr:check
goal interact with maven2 in a natural way in the case a development group
choose to use apache versioning. The check goal simply fails and gives a
useful warning.
Based on this reasoning I don't see why this should not be part of the
clirr:check goal.
The version plugin does not have anything for checking binary
compatibility: http://mojo.codehaus.org/versions-maven-plugin/ and exists to
to help with the manual management of pom version numbers.
Now this leaves the possibility that the clirr:check goal should instead be
a rule of the maven enforcer plugin?
If I do this work it will lead to duplication of clirr's functionality, the
enforcer goal would have very similar logic for artifact lookup and
resolution, and calling clirr.
I'm not opposed to doing the work to move the clirr:check goal and make it
an enforcer rule, but I would like some pointers to people to talk to first,
so I dont run into the same situation.
Thanks again for all your work on this, I really don't want to be
confrontational on MCLIRR-33. I simply think a lot of companies and
organizations could benefit from this. I know mine would greatly.
Rex
On Sun, Jul 11, 2010 at 10:25 AM, Evgeny Mandrikov <[email protected]>wrote:
> So, I've applied patches for MCLIRR-31 and MCLIRR-32. And MCLIRR-33
> closed with resolution "won't fix".
>
> Thanks for your contribution, Rex.
>
> On Sun, Jul 11, 2010 at 8:39 PM, Evgeny Mandrikov <[email protected]>
> 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_
> >
>
>
>
> --
> 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
>
>
>
