On 11 July 2010 23:37, Rex Hoffman <[email protected]> wrote: > Thank you very much. > > I finally noticed > org.apache.maven.artifact.versioning.DefaultArtifactVersion, and will try to > make ApacheVersionStandard extend it, or perhaps just be a helper class > related to DefaultArtifactVersion, > if that will make the patch more likely to be approved? > > I could also contact Brett Porter to see if he would accept a patch to the > DefaultArtifactVersion class? >
The problem is that you will be using the version of that class that ships with the version of maven that you are using to run your build. Go the helper class route. -Stephen > > Rex > > On Sun, Jul 11, 2010 at 3:23 PM, Evgeny Mandrikov <[email protected]>wrote: > >> Rex, Arnaud, thanks for your detailed explanation. I've reopened >> MCLIRR-33 and I'll review it more carefully, but just a bit later. >> >> 2010/7/11 Arnaud Héritier <[email protected]>: >> > 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 >> > >> > >> > >> >> >> >> -- >> 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 >> >> >> >
