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
