Nah, i'll just release it again. On Thu, Nov 4, 2010 at 2:31 PM, Rex Hoffman <r...@e-hoffman.org> wrote: > 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 >> >> >
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
