15

I have a POM which declares web application stuff that is common to my projects. I use this as the parent for all web applications.

Is it possible to activate a profile only when the packaging is war? I have tried the property approach, but that doesn't work (as it isn't a system/environment property).

Since this fails the build, I can simply disable that profile when installing the POM, but I'd like it to be more intelligent on its own.

Walter

Pascal Thivent
  • 562,542
  • 136
  • 1,062
  • 1,124
  • 2
    This type of advanced profile activation is not implemented yet http://jira.codehaus.org/browse/MNG-4154 – anttix Sep 12 '12 at 15:29
  • The issue mentioned by @anttix has been [moved](https://issues.apache.org/jira/browse/MNG-4154) and automatically closed. – Didier L Apr 13 '22 at 18:16
  • 2
    It's possible since [Maven 3.9.0](https://issues.apache.org/jira/browse/MNG-6609) – ZhekaKozlov Feb 19 '23 at 14:03

5 Answers5

16

You can simply check the existence of src/main/webapp. Each web application that uses the Maven standard directory layout should contain this folder. So you avoid unnecessary dummy files.

<profile>
    <id>custom-profile-eclipse-project-generation-webapp</id>
    <activation>
        <file>
            <exists>${basedir}/src/main/webapp</exists>
        </file>
    </activation>
    <build>
    </build>
</profile>

More precise you can also check for the the existence of ${basedir}/src/main/webapp/WEB-INF/web.xml. That should definitively identify a war-project.

For myself I use this configuration in my common super-pom to configure the maven-eclipse-plugin for different project types. Thats very handy to get homogenous eclipse-configurations over the same project type in our organization, especially when developers straightforwardly run eclipse:eclipse on multi-module-projects.

shylynx
  • 597
  • 1
  • 7
  • 25
  • Alternatively check for file that exists only in directory with parent/aggregate pom. This way it is IMO more robust. For example: SOME_FILE_THAT_EXISTS_ONLY_IN_DIRECTORY_WITH_AGGREGATE_POM – Rafał Kłys Feb 13 '20 at 14:47
5

I know this isn't answering your question directly, but the usual workaround for problems like this is to just use specialization (as with classes).

So you have your MasterPom with all common behavior.

MasterWarPom that extends MasterPom (is it's parent), and put any 'packing is war' specializations in here.

Likewise you could have MasterJarPom, etc ...

That way the differences are split out nicely.

lucas1000001
  • 2,740
  • 1
  • 25
  • 22
  • That is exactly what I'm doing. This is my abstract web application pom, the problem is, the key generation part wants to run on the package phase. What I do when I install/deploy the pom is disable that profile. –  Aug 22 '10 at 23:51
2

There's no clean way to do that, the parent module has no way of knowing the child's packaging. (Non-clean solutions would involve creating a plugin that parses the child module's pom etc.)

Sean Patrick Floyd
  • 292,901
  • 67
  • 465
  • 588
  • Why can't a simple activation do? For instance, in the parent pom, you say, activate when project.packaging = war or jar. When the child's packaging overrides the parent's packaging of pom, then the profile is activated. Would it be possible to write such an activation? –  Aug 23 '10 at 14:55
  • 1
    I am pretty sure that is not how profile inheritance works. The parent will switch on the profile or not, but the child will not inherit the switching-on logic, only what's inside the profile. – Sean Patrick Floyd Aug 23 '10 at 15:08
0

The best I've been able to come up with for these sorts scenarios has been to use a file-based activation trigger. eg my parent pom has

<profile>
   <id>maven-war-project</id>
   <activation>
     <file><!-- add a file named .maven-war-project-marker to webapp projects to activate this profile -->
       <exists>${basedir}/.maven-war-project-marker</exists>
     </file>
   </activation>
   <build>
     <plugins>
   <!-- configuration for webapp plugins here  -->
     </plugins>
   </build>

and webapp projects that inherit from this parent contain a file named '.maven-war-project-marker' that activates the profile

This looks pretty obtuse but works fairly reliably whereas - using property-activation is unreliable if a different person or system does the build, - inheriting from type-specific parents became a bit cumbersome for me as the grandparent-pom changes version relatively frequently as it is used to define 'standard' or preferred versions of common dependencies which in turn required corresponding releases of all of the type-specific parents with no change other than the grandparent version

user2878368
  • 1
  • 1
-2

Try in this way ?

mvn package -Dmaven.test.skip=true -Dwar

<project ×××××>
<modelVersion>4.0.0</modelVersion>
<parent>
    <groupId>××××</groupId>
    <artifactId>×××××</artifactId>
    <version>×××××</version>
    <relativePath>../../</relativePath>
</parent>
<artifactId>×××××</artifactId>
<name>${project.artifactId}-${project.version}</name>
<description>${project.artifactId}-${project.version}</description>
<properties>
    <packaging.type>jar</packaging.type>
</properties>
<profiles>
    <profile>
        <activation>
            <property>
                <name>war</name>
            </property>
        </activation>
        <properties>
            <packaging.type>war</packaging.type>
        </properties>
        <build>
            <finalName>ROOT</finalName>
        </build>
    </profile>
</profiles>
<packaging>${packaging.type}</packaging>
<dependencies>
    <dependency>
        ... ...
    </dependency>
    ... ... 
</dependencies>

FangKun Cao
  • 1
  • Hi! Welcome to StackOverflow -- Can you add to your answer by explaining how it answers the question being asked? – bwegs Oct 24 '14 at 04:06
  • 1
    Externalising the packaging type complicates the Maven configuration unnecessary. – shylynx Oct 27 '14 at 08:05