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. Rex On Thu, Nov 4, 2010 at 11:12 AM, Brian Fox <bri...@infinity.nu> wrote: > > If I were to clean this up and construct an enforcer rule that > > demanded adherence to the letter of the law of the apache version > > standard, is something that would be allowed into the maven enforcer > > plugin? > > > > Given a proper rule with tests, I would unlikely reject it out of hand. > > > Or would the team prefer I continue to try to work the the clirr-mojo? > > > > My gut though is that this might be better as a report than a rule. I > think an enforcer rule could get in the way of developers if as soon > as they made a breaking change, the build blew up on them. It would > make a bit more sense in a release profile but even there blowing up a > build is annoying. > > What belongs in the enforcer vs other plugins is definitely a grey > area that has no great answer. Certainly I could make a rule to > duplicate checkstyle and pmd checks, but those plugins have ways of > failing the build already. The enforcer wasn't intended to become the > central place for all things that fail a build, although it could. > > Given that there seems to be great overlap with the clirr stuff in > checking the api, it feels like the functionality should be there. > However, if you construct it as a separate plexus component, then both > clirr and the enforcer could use that shared code to provide multiple > ways to attack it. > > > Give me a firm commitment (contingent on quality of course ) and I > > could have this done tonight. > > > > Rex > > > > --------------------------------------------------------------------- > > 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 > > -- Rex (415) 273-9438 http://www.e-hoffman.org
