> 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
