You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Andreas Sewe <se...@st.informatik.tu-darmstadt.de> on 2010/12/16 21:15:04 UTC
Chicken-and-egg problem: plugin dependencies as modules
Hi all,
I am experiencing a kind of chicken-and-egg problem in my usage of the
m-pmd-p, the m-checkstyle-p, and the m-license-p. All these plugins are
capable of loading their respective configurations (rulesets or license
headers) from the plugin's classpath. As such it seems sensible to
create dedicated ruleset or license-header Maven projects, which the
respective plugins then depend on.
Problems start, however, if those ruleset or license-header projects are
modules of a common parent project, which configures the respective
plugins for all its descendants:
parent (configures m-pmd-p with "ruleset" project as plugin dependency)
|
+-- ruleset
|
+-...- any other project that should be subject to m-pmd-d checks.
This, of course, introduces a cycle in the projects dependencies; you
cannot build "parent" without building "ruleset" first, which itself
inherits from "parent".
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
best practices and recommendations?
Best wishes,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Chicken-and-egg problem: plugin dependencies as modules
Posted by Andreas Sewe <se...@st.informatik.tu-darmstadt.de>.
Hi Stephen,
> 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.
True.
But its a little bit tricky to get this setup off the ground in the
first place:
1. Release version 1.0 of organizational POM
(without m-pmd-p)
2. Release version 1.0 of ruleset
(inheriting from organizational POM, version 1.0)
3. Release version 2.0 of organizational POM
(with m-pmd-p and ruleset, version 1.0)
And the ruleset is doomed to perpetually lag behind one version of the
organizational POM.
I think I like the two-parents solution better: the organizational POM
is restricted to (plugin|dependency)Management, with the other parent
binding plugins for real.
Best wishes,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Chicken-and-egg problem: plugin dependencies as modules
Posted by Stephen Connolly <st...@gmail.com>.
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
<se...@st.informatik.tu-darmstadt.de> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Chicken-and-egg problem: plugin dependencies as modules
Posted by Andreas Sewe <se...@st.informatik.tu-darmstadt.de>.
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Chicken-and-egg problem: plugin dependencies as modules
Posted by Wayne Fay <wa...@gmail.com>.
> 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.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org