Maven Profile - Activate Profile depending on packaging

Question

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

Funda

This type of advanced profile activation is not implemented yet jira.codehaus.org/browse/MNG-4154 – Carminecarmita

The issue mentioned by @Carminecarmita has been moved and automatically closed. – Lhasa

It's possible since Maven 3.9.0 – Queridas

Answer 1

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.)

Adigranth

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? – Funda

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. – Adigranth

Answer 2

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.

Kneecap

Alternatively check for file that exists only in directory with parent/aggregate pom. This way it is IMO more robust. For example: <activation><file><missing>SOME_FILE_THAT_EXISTS_ONLY_IN_DIRECTORY_WITH_AGGREGATE_POM</missing></file></activation> – Haubergeon

This was a great solution. I used it for putting stuff in my parent POM that only activates for a maven-plugin child POM, so I didn't have to create two separate parent POMs (one for maven plugins and one for regular jar projects). The only annoying thing is that I have to create a special file in my maven plugin projects. I created a custom file in src/main/resources/META-INF for this purpose. – Helsie

Answer 3

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.

Scoundrel

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. – Funda

Answer 4

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

Garnet

Answer 5

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>

Exequatur

Hi! Welcome to StackOverflow -- Can you add to your answer by explaining how it answers the question being asked? – Zeidman

Externalising the packaging type complicates the Maven configuration unnecessary. – Kneecap