Hi Stephen and Martin
Thanks for your constructive contribution :-)
As we implement a framework it is important to leave the user pom files as
clean as possible to avoid tedious upgrades when we change the implementation.
Currently I inject the following stuff using profiles with file exists
condition:
1.) dependencies (type compile and provided)
...
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.3</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.nsn.see.sce.container.sipservlet</groupId>
<artifactId>container-sipservlet-api</artifactId>
<version>${sceVersion}</version>
<scope>compile</scope>
</dependency>
...
2.) plugin configuration e.g.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<webXml>${project.basedir}/WebContent/WEB-INF/web.xml</webXml>
<webResources>
<resource>
<directory>${project.basedir}/WebContent/WEB-INF</directory>
<targetPath>WEB-INF</targetPath>
<includes>
<include>weblogic.xml</include>
<include>sip.xml</include>
</includes>
<filtering>false</filtering>
</resource>
</webResources>
</configuration>
</plugin>
</plugins>
</build>
3.) plugin management configurations
4.) properties
The only negative sideeffect the profile workaround currently has is that the
dependencies cannot be used transitively as the file marker is not in
repository. I just wonder if I could replace the dependencies with the import
feature. Will import also add the provided dependencies?
/Richard
-----Original Message-----
From: ext Stephen Connolly [mailto:[email protected]]
Sent: Thursday, April 14, 2011 2:23 PM
To: Maven Users List
Cc: Martin Gainty
Subject: Re: Expected implementation date for Maven MIXIN Feature
http://www.mail-archive.com/[email protected]/msg85145.html
On 14 April 2011 13:16, Martin Gainty <[email protected]> wrote:
>
> you may want to consider aggregating your plugins into a
> dependency-management block
> then further down have your poms pull in that dependency-management block of
> plugins with <scope>import</scope>
> in the calling poms dependency-management dependency
>
> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
>
> if this doesnt suit your need we could provide a better solution if
> you could provide specifics on what you are attempting to accomplish
>
> gruss
> Martin
> ______________________________________________
> Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
>
> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
> sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung
> oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich
> dem Austausch von Informationen und entfaltet keine rechtliche
> Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen
> wir keine Haftung fuer den Inhalt uebernehmen.
> Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
> destinataire prévu, nous te demandons avec bonté que pour satisfaire informez
> l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci
> est interdite. Ce message sert à l'information seulement et n'aura pas
> n'importe quel effet légalement obligatoire. Étant donné que les email
> peuvent facilement être sujets à la manipulation, nous ne pouvons accepter
> aucune responsabilité pour le contenu fourni.
>
>
>
>
>> Subject: RE: Expected implementation date for Maven MIXIN Feature
>> Date: Thu, 14 Apr 2011 11:50:06 +0200
>> From: [email protected]
>> To: [email protected]
>>
>> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
