If the plugins are orthogonal to the module types then just bung it
all in the root pluginManagement and be done with it.
I am assuming that you have a non-orthogonal case though. In the
non-orthogonal case you could stop having inheritance follow
aggregation. it would mean some duplication in the child poms (need to
specify /project/version, /project/url, /project/scm,
/project/distributionManagement/site) and you'd probably want to add
to /project/dependencyManagement/dependencies
<dependency>
<groupId>aggregation-parent-groupId</groupId>
<artifactId>aggregation-parent-artifactId</artifactId>
<version>${project.version}</version> <!-- you have specified it
explicitly so using this will help break the build if things get out
of sync -->
<type>pom</type>
<scope>import</scope>
</dependency>
So that the aggregation can enforce dependency management on all its
child modules.
That's about the closest you can get to the MIXIN proposal today.
-Stephen
On 14 April 2011 10:50, Bock, Richard (NSN - DE/Munich)
<[email protected]> wrote:
> Hi Anders,
>
> Thanks for your clarifications. I try get the wordings right. But what
> are you actually suggesting? I mean stay away from profiles. Yeah. But
> what to use instead? Modules will not work as I am actually already
> using them. I need modules that have an aggregation parent and still get
> some model type specific configuration (plugins e.g. that are always
> same for a certain module type).
>
> Currently using profiles and <activation><file><exists> is only a
> workaround. I am still curious to get a reply from some Maven
> contributor on whether this problem can be solved with MIXIN and when
> MIXIN will be available.
>
> Using profiles in this manner has the advantage that all module pom
> files are using the traditional aggregation parent but do not contain
> any redundant plugin configurations that are related to the module type
> (e.g. modeling project, java implementation project, web service project
> and so on)
>
> /Richard
>
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of ext Anders Hammar
> Sent: Thursday, April 14, 2011 11:09 AM
> To: Maven Users List
> Subject: Re: Expected implementation date for Maven MIXIN Feature
>
> Please, don't call it a super-pom. There is only one (and will only be
> just
> one) super-POM and it lives in Maven core. What you are talking about is
> a
> parent-pom and should be called that.
>
> Also, you're talking about archetypes which is something completely
> different from "artifacts" which I believe you're referring to. Please
> pay
> attention to the wording as it makes it easier for other people to
> understand what you're explaining.
>
> As you've noticed, the actual profile isn't inherited but rather the
> effect
> of the profile. One of those tricky things with profiles but that's by
> design. The simplest thing is to try staying away from profiles all
> together
> as they very often trick you into doing something which isn't the Maven
> Way..
>
> /Anders
>
> On Wed, Apr 13, 2011 at 20:32, Bock, Richard (NSN - DE/Munich) <
> [email protected]> wrote:
>
>> Today I found a workaround which is somehow not optional but keeps me
>> alive.
>>
>> All the base artifact types of a certain platform type will be put
> into a
>> super-pom for that platform type. E.g. jee-super-pom. Each artifact
> base
>> type plugin and properties is encapsulated into a Profile. The profile
> is
>> activated by a file that exists in the child project.
>>
>> Now the aggregator project myapp-pom can inherit from the
> jee-super.pom.
>>
>> Each module module-pom will have a file e.g. javalib-architype,
>> groovylib-architype, basemodel-architype, testimpl-architype. This
> will
>> activate the base architype profiles.
>>
>> Drawback is that this leaves the module-pom projects with funny empty
>> marker files in the project folder and the files cannot be looked up
> in the
>> repository as they are no architypes.
>>
>> What I find rather annoying is that even the activiation condition
> based on
>> properties will not work as the parent profiles will only be triggered
> by
>> parent properties and not by properties defined in the module-pom.
>>
>> So I just hope someday or earlier then later someone will add a
> feature to
>> Maven to resolved the parent properties, then the child properties and
> then
>> start resolving the profiles only.
>>
>> Or let us keep the hope up some one delivers the MIXIN feature.
>>
>> /Richard
>>
>>
>> -----Original Message-----
>> From: ext Wayne Fay [mailto:[email protected]]
>> Sent: Wednesday, April 13, 2011 8:19 PM
>> To: Maven Users List
>> Subject: Re: Expected implementation date for Maven MIXIN Feature
>>
>> > AM gets the version from A through the parent relationship.
>> > AM gets the plugin sce.model from the MIXIN relationship to M.
>> >
>> > AI gets the version from A through the parent relationship.
>> > AI gets the plugin sce.compile from the MIXIN relationship to I.
>>
>> Sounds roughly like composition of objects/projects in the POM, is
>> that about right? I haven't really been following any discussion of
>> Mixins previously.
>>
>> Wayne
>>
>> ---------------------------------------------------------------------
>> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
