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]
