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]