No, it will not.
As you've already seen, adding dependencies through a profile is a very bad
thing to do. You must understand that using Maven isn't just about making
your build work but also making sure that dependency management for those
using (consuming) your artifact works. When you add dependencies in a
profile this most often gets screwed up.
/Anders
On Fri, Apr 15, 2011 at 00:29, Bock, Richard (NSN - DE/Munich) <
richard.b...@nsn.com> wrote:
> 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:stephen.alan.conno...@gmail.com]
> 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/dev@maven.apache.org/msg85145.html
>
> On 14 April 2011 13:16, Martin Gainty <mgai...@hotmail.com> 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: richard.b...@nsn.com
> >> To: users@maven.apache.org
> >>
> >> 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: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] 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) <
> >> richard.b...@nsn.com> 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:wayne...@gmail.com]
> >> > 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: users-unsubscr...@maven.apache.org
> >> > For additional commands, e-mail: users-h...@maven.apache.org
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
