On Thu, Nov 4, 2010 at 11:28 AM, 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. > > "Hold off on the release" that is.... only one typo in this message, I can live with that.... > 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 > >
