The problem is that the profile activation gets only evaluated once when the parent pom is
parsed (just tried it) so all approaches based on the evaluation of some criteria in a
subproject will fail (including the properties, packaging and marker file approaches).
We do it like Wim and have a parent pom per project type.
-Tim
Eric Redmond schrieb:
I know this is also not a super-elegant solution, however, what about
activating profiles on the existance of files?
Such as, web.xml for a war, or application.xml for an EAR?
As I said, not the best, but it should save you from messing up your POM
hierarchy.
Eric
On 4/8/06, Wim Deblauwe <[EMAIL PROTECTED]> wrote:
Yep,
We are using it like that in m1 (no profiles there, so no other choice).
When doing the conversion to m2, I created a "build project" with
build-base, build-jar, build-war, build-dll, ... all using pom packaging.
The conversion is still going on, but that is a different story :)
You don't need to use the relative reference by the way. In fact, I don't
understand why they still support that. I like the idea of "releasing"
your
pom as a version better and then just define the parent using the normal
group, artifact and version things. That way, you are independent of the
location of those pom relative to your own project.
good luck,
Wim
2006/4/8, Wayne Fay <[EMAIL PROTECTED]>:
An interesting thought...
So you'd have:
project/pom.xml (packaging pom; modules jar, war, ear; parent
../pom.xml)
project/jar/pom.xml (packaging pom; module jar; parent ../pom.xml)
project/jar/jar/pom.xml (packaging jar; parent ../pom.xml)
project/war/pom.xml (packaging pom; module war; parent ../pom.xml)
project/war/war/pom.xml (packaging war; parent ../pom.xml)
etc
Is that what you're saying?
Never tried but sounds like it would be worth a shot as a possible
solution to the problem...
Wayne
On 4/8/06, Wim Deblauwe <[EMAIL PROTECTED]> wrote:
another solution is to use different parent poms. Have a parent pom
defining
all you need for that certain type. Each type refers to the proper
parent
pom. You can even have a master parent pom above those parent pom for
things
that are equal for all types.
regards,
Wim
2006/4/7, Wayne Fay <[EMAIL PROTECTED]>:
Sounds like a reasonable profile activation method. File a JIRA
Enhancement request.
Wayne
On 4/7/06, John Didion <[EMAIL PROTECTED]> wrote:
That would be a lovely solution...unfortunately the property
activation
refers to system properties (i.e. specified on the command line),
not
project properties.
I think you're right about packaging. It would be great to have a
<packaging> profile activation.
-----Original Message-----
From: Tim Kettler [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 06, 2006 10:51 PM
To: Maven Users List
Subject: Re: Can I activate a profile based on module type?
Hi,
I never tried this but I think this could/should work:
1. You define the profiles in your parent pom like this
<profiles>
<profile>
<id>library</id>
<activation>
<property>
<name>moduletype</name>
<value>jar</value>
</property>
</activation>
...
</profile>
<profile>
<id>webapp</id>
<activation>
<property>
<name>moduletype</name>
<value>war</value>
</property>
</activation>
...
</profile>
</profiles>
2. In your modules you then define the property as needed
<properties>
<moduletype>lib</moduletype>
</properties>
The most elegant solution would be to not use a custom defined
property at
all but the
vaule of the <packaging/> element of the module poms but I don't
know
if
the content is
made available as a property.
-Tim
John Didion schrieb:
I have a project with several different types of modules -
some
are
libraries (stand-alone jars), some are wars, some are
executables
(jars
plus some extra plugins to generate batch files and create an
assembly).
I would like to put the configuration for all these different
project
types in to my top-level pom, and then have each module
activate
only
the plugin configurations that apply to its type. Profiles
seem
a
natural way to do this, but I can't find any way to explicitly
activate
them from a module.
Using the activeProfiles element in settings.xml doesn't make
sense
since the profile I want to activate will differ depending on
the
module. I tried using a profiles.xml and setting the
activeProfiles
there, but unfortunately that only applies to the profiles
defined
in
profiles.xml.
Is there another way to do what I want?
Here's an example:
pom.xml
-------------
<project>
<groupId>test</groupId>
<artifactId>parent</artifactId>
<profile>
<id>library</id>
<pluginManagement>
<plugins>
<plugin>
<groupId>foo</groupId>
<artifactId>foo</artifactId>
<configuration>
...
</configuration>
</plugin>
</plugins>
</pluginManagement>
</profile>
<profile>
<id>webapp</id>
<pluginManagement>
<plugins>
<plugin>
<groupId>foo</groupId>
<artifactId>foo</artifactId>
<configuration>
... (different than the library profile's
configuration)
</configuration>
</plugin>
</plugins>
</pluginManagement>
</profile>
</project>
child/pom.xml
---------------------
<project>
<parent>
<groupId>test</groupId>
<artifactId>parent</artifactId>
</parent>
<groupId>test</groupId>
<artifactId>child</artifactId>
...what do I do here to activate the library profile?...
</project>
---------------------------------------------------------------------
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]
