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 > >
