I thought you were going to rework the patch... If you have reworked the patch, then ping the d...@mojo list again...
given that the feeling is that m-enforcer-p is not a good fit (because of phases) and given that v-m-p is not a good fit (because I'm going to insist that v-m-p does not have anything to do with failing the build), clirr-m-p is the natural home of your extended functionality... if you are providing a clean patch which uses a helper method to delegate to DefaultArtifactVersion, then I cannot see why this will not be applied -Stephen On 5 November 2010 18:53, Rex Hoffman <r...@e-hoffman.org> wrote: > Hmm... good point about the phase.... i'll have to think on that. We can > always have two executions for the plugin, or perhaps the plugin should > allow a rule to specify what phase it wants to be run in, thought that would > be harder to pull off. Though probably more correct. > > I have already written this version check as a patch for clirr. > The current maintainers just seem unwilling to adopt it. > See: http://jira.codehaus.org/browse/MCLIRR-33 > > Also have it compiled here: > https://www.e-hoffman.org/released/repo/org/codehaus/mojo/clirr-maven-plugin/2.3.0/ > > Usage is as simple as: > > <configuration> > <failBasedOnApacheVersionNumberStandard>true</failBasedOnApacheVersionNumberStandard> > <strictVersionNumber>true</strictVersionNumber> > </configuration> > > MNG-3826 is unnecessary, because the clirr plugin itself can make the > distinction, simply by looking at your current version number and all prior > released version. > > Also, from there it's not hard to ensure no visible changes on patch number. > > I do think I need to go in an change the behavior for interfaces. Currently > clirr thinks any change to an interface is backwards breaking... on the > assumption that every consumer of the jar will implement that interface. I > don't believe most developers work that way with interfaces anymore. In > general I think we work more like slf4j, where we define an API made of > interfaces in a jar. Some packages implement it (so the changes for them > force code changes -- which is to be expected and wont require checking > functionality.... they failed compile will tell the dev what's up). But > almost every other package just uses that API. So my code does have a known > bug I have to clean up. > > But again, the mojo devs have very little interest in this, and I'd rather > we have a apache version standard plugin that happens to use clirr, rather > than a clirr plugin that happens to enforce the apache version standard. > > Rex > > On Fri, Nov 5, 2010 at 3:32 AM, Mark Hobson <markhob...@gmail.com> wrote: > >> On 4 November 2010 18:28, Rex Hoffman <r...@e-hoffman.org> wrote: >> > Seems reasonable, build a helper library to run clirr and analyze it's >> > results, allow the clirr plugin to use it in it's existing manner, or by >> an >> > enforcer rule. >> > >> > That fact that it's clirr under the hood of that enforcer rule will be >> > completely abstracted. This will be a rule to enforce apache version >> > standard, that happens to use clirr. I'll write a clean api for it's >> > analysis provider (clirr). >> > >> > I know it'll be annoying, that's kinda the point. If your working on a >> > 1.1-SNAPSHOT and create a backwards breaking change, you have messed up. >> > The rule will tell the dev to correct the method, or bump the version >> > number to 2.0-SNAPSHOT. The real danger is a dev not being aware that >> they >> > have produced a backwards breaking change. Again, very helpful for apis. >> > >> > Given Brett's email today citing the desire for >> > >> > " >> > Configurable conflict resolution strategy - newest, oldest that satisfies >> > Enforcer rule to lock down above >> > Importance of specificity, not magic - break the build if conflicting >> > versions, not try and solve it >> > Be deterministic is maven's strength >> > " >> > >> > I think it's important we codify how maven wants devs to think about >> > versions. Right now it a snapshot or release. The ranges have vague >> > meaning at best, not knowing what version policy the project you depend >> on >> > follows. >> > >> > If you want to hold of the release until Monday, I will commit to having >> it >> > done and tested by then?? >> > >> > I think having the dependency-convergence rule and this rule will do a >> lot >> > for many organization that have or are adopting maven. I know it >> definitely >> > helped at the last place I worked. >> >> Enforcing no API breaking changes within minor versions has been on my >> wish list for a while too. My plan was to use the Clirr plugin in a >> profile that is only activated for minor versions. This latter point >> requires something like MNG-3826 though. >> >> Personally I feel that this check is beyond the scope of the enforcer. >> By default the enforcer runs at validate phase, way before classes >> are compiled for Clirr, so I'd feel happier achieving this in the >> verify phase using clirr:check. It is a hazy line between enforcer >> rules and other plugin goals, but I'd suggest using rules for (fast) >> environment and POM checks and other plugins for (slower) checks that >> require results of lifecycle phases. >> >> Mark >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
