CODEWITHSUNDEEP
maven-2profiles
Walter White
Walter White

Reputation:

Maven Profile - Activate Profile depending on packaging

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

Upvotes: 15

Views: 4953

Answers (5)

FangKun Cao
FangKun Cao

Reputation: 1

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>

Upvotes: -2

shylynx
shylynx

Reputation: 615

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.

Upvotes: 17

user2878368
user2878368

Reputation: 1

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

Upvotes: 0

Sean Patrick Floyd
Sean Patrick Floyd

Reputation: 299178

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

Upvotes: 2

lucas1000001
lucas1000001

Reputation: 2750

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.

Upvotes: 5

Related Questions