The organizational pom can prescribe the use of the most recently released ruleset.
The next version of the ruleset would "technically" be checked against the previous version, but as rulesets are not java code the check will not be applied on that artifact. -Stephen On 17 December 2010 11:55, Andreas Sewe <[email protected]> wrote: > Hi Wayne, > > thanks for the advice. > >>> What's the best way to resolve this kind of chicken-and-egg problem >>> without introducing too many extra projects just to break the cycle? Any >> >> This is exactly what you have to do. The rulesets should be packaged >> and versioned independent of the project. Ideally you'd have one >> corporate ruleset and all your various projects would just use it. > > But the ruleset project should inherit from the organizational POM -- as all > good projects in our organization do. Now, that would imply that the > organizational POM cannot prescribe the use of the ruleset, as this would > result in a cyclic dependency. > > What's the way out of this? Is something like the following considered best > practice? > > organizational POM > | > +-- ruleset > | > +-- project parent (configures p-pmd-plugin with "ruleset" dependency) > | > +-...- any other project that should be subject to m-pmd-d checks. > > Best wishes, > > Andreas > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
