I have a scenario wherein my project needs to be compiled in different JDKs and the resulting artifact name should be different based on the JDK used. For example if the project name is MyProject and I call mvn install then it needs to be compiled in JDK 1.4 as well as JDK 1.5, and finally I get two jars of the same project (MyProjectJDK14-1.0 and MyProjectJDK15-1.0). Is is possible to achieve this?
The Maven way to do this is not to change the finalName of the artifact but to use a classifier. For example:
<project>
...
<build>
<plugins>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<classifier>${envClassifier}</classifier>
</configuration>
</plugin>
</plugins>
</build>
...
<profiles>
<profile>
<id>jdk16</id>
<activation>
<jdk>1.6</jdk>
</activation>
<properties>
<envClassifier>jdk16</envClassifier>
</properties>
</profile>
<profile>
<id>jdk15</id>
<activation>
<jdk>1.5</jdk>
</activation>
<properties>
<envClassifier>jdk15</envClassifier>
</properties>
</profile>
</profiles>
</project>
The JAR artifact will be named ${finalName}-${envClassifier}.jar and included as a dependency using the following syntax:
<dependency>
<groupId>com.mycompany</groupId>
<artifactId>my-project</artifactId>
<version>1.0</version>
<classifier>jdk16</classifier>
</dependency>
You'll have to call the Maven build twice to produce both jars (a decent CI engine can do that).
What you can do is to define two profiles, one per JDK used. Each profile will be activated regarding which JDK is used:
<profiles>
<profile>
<id>profile-for-jdk1.4</id>
<activation>
<activeByDefault>false</activeByDefault>
<jdk>1.4</jdk>
</activation>
<build>
<finalName>myBuild-jdk1.4</finalName>
</build>
</profile>
<profile>
<id>profile-for-jdk1.5</id>
<activation>
<activeByDefault>false</activeByDefault>
<jdk>1.5</jdk>
</activation>
<build>
<finalName>myBuild-jdk1.5</finalName>
</build>
</profile>
</profiles>
Then, in each profile, you define a specific <finalName>, which will be used to name the generated JAR file.
Thus, if you build your application using JDK 1.4, the generated JAR will be named myBuild-jdk1.4.jar.
If your final package is built using an assembly, you can simply change the <build> block inside profiles to configure the assembly plugin (for example to <finalName>).
Regarding your comment: Indeed, this procedure will need two separate builds on Maven, as you have to recompile the whole project when changing the JDK version. One of the Maven2 convention is that one project = one artifact. What you want is to have one project with two artifacts.
Eventually, one solution is to use Hudson to build your application, and especially the matrix feature of this tool, which allows you to run multiple builds with various parameters, in your case the JDK.
Use Maven Profiles. Add this section inside the project tag of your pom.xml:
<profiles>
<profile>
<activation>
<jdk>1.4</jdk>
</activation>
<build>
<finalName>${project.artifactId}-${project.version}-JDK1.4</finalName>
</build>
</profile>
<profile>
<activation>
<jdk>1.5</jdk>
</activation>
<build>
<finalName>${project.artifactId}-${project.version}-JDK1.5</finalName>
</build>
</profile>
</profiles>
See this to know more about profiles.
A similar problem is the different variants of the JDBC api used in different versions of the JDK.
I decided that these needed different arifactIds rather than classifiers.
You can achieve this by setting a property in settings and then referencing this in the artifactId tag:
<project>
<modelVersion>4.0.0</modelVersion>
<artifactId>throwing-jdbc-${jdbc.version}</artifactId>
<name>Throwing JDBC</name>
<profiles>
<profile>
<id>jdbc3</id>
<activation>
<activeByDefault>false</activeByDefault>
<jdk>[1.3,1.4,1.5]</jdk>
</activation>
<properties>
<jdbc.version>3.0</jdbc.version>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.7</version>
<configuration>
<sources>
<source>src/jdbc3-variants/java</source>
</sources>
</configuration>
<executions>
<execution>
<goals>
<goal>add-source</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
<profile>
<id>jdbc4</id>
<activation>
<activeByDefault>false</activeByDefault>
<jdk>1.6</jdk>
</activation>
<properties>
<jdbc.version>4.0</jdbc.version>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.6</source>
<target>1.6</target>
</configuration>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<configuration>
<sources>
<source>src/jdbc4/java</source>
<source>src/jdbc4-variants/java</source>
</sources>
</configuration>
<executions>
<execution>
<goals>
<goal>add-source</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
<profile>
<id>jdbc41</id>
<activation>
<activeByDefault>false</activeByDefault>
<jdk>1.7</jdk>
</activation>
<properties>
<jdbc.version>4.1</jdbc.version>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<configuration>
<sources>
<source>src/jdbc4/java</source>
<source>src/jdbc4.1/java</source>
<source>src/jdbc4.1-variants/java</source>
</sources>
</configuration>
<executions>
<execution>
<goals>
<goal>add-source</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<sourceDirectory>src/main/java</sourceDirectory>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>2.2.1</version>
<executions>
<execution>
<phase>verify</phase>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
There is actually a way to produce more than one WAR with one build (I guess this works for JARs as well): you can use the assembly plugin with multiple executions for different descriptors.
Related
I am creating a maven 2 build for a project and I came up with profiles since the build has to be created for both different locations (say Berlin, Paris, North Pole) and different environment (Development, Production). Those are specified via properties. So for "North Pole" "DEV" I do:
-Dlocation=NorthPole -Denvironment=DEV
Now I would like to acivate my porfile based on both these properties, not just one. So I tried following:
<profiles>
<profile>
<id>NOrth Pole DEV</id>
<activation>
<property>
<name>location</name>
<value>NorthPole</value>
</property>
<property>
<name>environment</name>
<value>DEV</value>
</property>
</activation>
... <!-- Set some North Pole DEV specific stuff -->
</profile>
</profiles>
This doesn't work, maven expect to see at most one <property> element there.
Please note I have another use for the properties as well so making it single property locationEnvof value NorthPole-DEV isn't what I want to have.
So is there any way or workaround or whatever else how to activate an profile based on combination of properties?
I am afraid there is no good solution to your problem (unless there are new Maven features I am not aware of).
In theory, you could introduce a derived property whose value is concatenated from the two properties you listed. However, the problem is that profiles are evaluated before properties defined in the pom, so such a derived property can't be used to activate a profile :-(
The best workaround I could think of for a similar problem was to activate the profile explicitly, and put the different combinations of command line parameters into separate batch/script files to make execution simpler and avoid mistyping issues.
why not using profile directly like:
<profiles>
<profile>
<id>north-pole</id>
<activation>
<activeByDefault>false</activeByDefault>
</activation>
....
</profile>
<profile>
<id>dev</id>
<activation>
<activeByDefault>false</activeByDefault>
</activation>
....
</profile>
</profiles>
Now you can activate the profiles by command line.
mvn -Pdev,north-pole ...
Possible Solution
Try this extension: https://github.com/kpiwko/el-profile-activator-extension
This allows to have such syntax:
<profile>
<id>NOrth Pole DEV</id>
<activation>
<property>
<!-- mvel property name is obligatory -->
<name>mvel</name>
<value>isdef location && location=="NorthPole" &&
isdef environment && environment=="DEV"</value>
</property>
</activation>
</profile>
I did not try it myself, but seems to be a nice project.
How to avoid manual configuration of Maven
You need to put the needed two jars of the project into $MAVEN_HOME/lib/ext. You can however automize configuring them. Like this:
You can add a profile which is activated on absense of $MAVEN_HOME/lib/ext/el-profile-activator-extension.jar file
This profile can download the jars from maven using dependency plugin into the $MAVEN_HOME/lib/ext folder in init phase
Then you can write out a message, that the build configured the maven folder, and the next build will be successful.
Tested profile:
<profile>
<id>prepare-maven-extended-libs</id>
<activation>
<file>
<missing>${maven.home}/lib/ext/el-profile-activator-extension.jar</missing>
</file>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.8</version>
<executions>
<execution>
<id>copy</id>
<phase>validate</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>com.redhat.jboss.maven</groupId>
<artifactId>el-profile-activator-extension</artifactId>
<version>1.0.0-SNAPSHOT</version>
<type>jar</type>
<overWrite>true</overWrite>
<outputDirectory>${maven.home}/lib/ext</outputDirectory>
<destFileName>el-profile-activator-extension.jar</destFileName>
</artifactItem>
<artifactItem>
<groupId>org.mvel</groupId>
<artifactId>mvel2</artifactId>
<version>2.1.3.Final</version>
<type>jar</type>
<overWrite>true</overWrite>
<outputDirectory>${maven.home}/lib/ext</outputDirectory>
<destFileName>mvel2.jar</destFileName>
</artifactItem>
</artifactItems>
<outputDirectory>${project.build.directory}/wars</outputDirectory>
<overWriteReleases>true</overWriteReleases>
<overWriteSnapshots>true</overWriteSnapshots>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.gmaven</groupId>
<artifactId>gmaven-plugin</artifactId>
<version>1.4</version>
<executions>
<execution>
<phase>validate</phase>
<goals><goal>execute</goal></goals>
</execution>
</executions>
<configuration>
<source>
fail("For profile activation we use an extension jar. It is now in your ${maven.home}/lib/ext folder. Please restart the build, and then it will be successful.")
</source>
</configuration>
</plugin>
</plugins>
</build>
</profile>
khmarbaise's answer seems more elegant to me.
To Jan's comment, you can refer to the file by appending the properites
e.g. with profile dev, North Pole activated you can refer to NorthPole-dev.xml with
${location}-${env}.xml.
I had to post another reply as I'm not able to add comments to other's replies. :(
I believe you can do something like this
<properties>
<env>dev</env>
<location>North Pole</location>
</properties>
<profiles>
<!-- dev North Profile -->
<profile>
<id>dev North Pole</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
</profile>
<!-- qa North Profile -->
<profile>
<id>qa North Pole</id>
<properties>
<env>qa</env>
<location>North Pole</location>
</properties>
</profile>
</profiles>
<build>
do profile specific stuff here
</build>
Of couse, to activate a profile you can add in the command '-P=dev North Pole'
After an exhaustive investigation I've posted a video where I explain the usage of Maven profiles per environment with Spring Boot. That is a spring boot rest project that handle the application properties per environment using Maven profiles.
Here are the links:
Youtube: https://youtu.be/UbDpvh3YvDw
Github: https://github.com/carlosCharz/mavenprofilespringboot
Code snippet:
Application parameters
custom.server_url = #custom.server_url#
custom.server_port = #custom.server_port#
custom.debuggable = #custom.debuggable#
custom.image_quality = HIGH
Overrides parameters
custom.server_url = api-dev.yourserver.com
custom.server_port = 80
custom.debuggable = true
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.wedevol</groupId>
<artifactId>mvnspringboot</artifactId>
<version>1.0.0</version>
<packaging>war</packaging>
<name>Spring Boot Project with Maven</name>
<description>This is a spring boot rest project that handle the application properties per environment using Maven profiles.</description>
<properties>
<java.version>1.8</java.version>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
</properties>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.0.0.RELEASE</version>
<!-- https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.0-Release-Notes -->
</parent>
<dependencies>
<!-- Spring -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
<scope>provided</scope>
</dependency>
</dependencies>
<!-- Maven profile per environment -->
<profiles>
<profile>
<id>local</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<overrides.props.file>local.overrides.properties</overrides.props.file>
<current.profile>local</current.profile>
</properties>
</profile>
<profile>
<id>dev</id>
<properties>
<overrides.props.file>dev.overrides.properties</overrides.props.file>
<current.profile>dev</current.profile>
</properties>
</profile>
<profile>
<id>qa</id>
<properties>
<overrides.props.file>qa.overrides.properties</overrides.props.file>
<current.profile>qa</current.profile>
</properties>
</profile>
<profile>
<id>prod</id>
<properties>
<overrides.props.file>prod.overrides.properties</overrides.props.file>
<current.profile>prod</current.profile>
</properties>
</profile>
</profiles>
<build>
<finalName>mvnspringboot</finalName>
<!-- Maven Resources. It handles the copying of project resources to the output directory. -->
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
<excludes>
<exclude>profiles/*</exclude>
</excludes>
</resource>
</resources>
<!-- Maven filtering. The variables are included in the resources ( ${..} or #...# delimiters) -->
<filters>
<filter>src/main/resources/profiles/${overrides.props.file}</filter>
</filters>
<plugins>
<!-- Spring boot maven plugin -->
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
<!-- Ant plugin to print the current maven profile -->
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<phase>generate-resources</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo>Current maven active profile: ${current.profile}</echo>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
Let me know if it worked! Gretings!
With the maven jar plugin I build two jar: bar-1.0.0.jar and bar-1.0.0-client.jar.
Actually in my POM I have the following dependency:
<dependency>
<groupId>de.app.test</groupId>
<artifactId>foo</artifactId>
<version>1.0.0</version>
</dependency>
This artifact exist also in two version bar-1.0.0.jar and bar-1.0.0-client.jar
I want to make bar-1.0.0-client.jar dependent of foo-1.0.0-client.jar and bar-1.0.0.jar dependent of foo-1.0.0.jar.
================
->First (wrong) solution: define the scope as provided and use the right foo package when using bar.jar
->Second (long) solution : Add 'server' classifier to the other jar. Use different profile to build the foo artifact and put the classifier in a property.
<dependency>
<groupId>de.app.test</groupId>
<artifactId>foo</artifactId>
<version>1.0.0</version>
<classifier>${profile.classifier}<classifier>
</dependency>
================
Concerning the profile solution.
Interfaces module pom
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<parent>
<groupId>com.app</groupId>
<artifactId>myapp-parent</artifactId>
<version>1.1.0</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<groupId>com.app</groupId>
<artifactId>myapp-interfaces</artifactId>
<version>1.1.0-SNAPSHOT</version>
<packaging>jar</packaging>
<name>myapp Interfaces</name>
<profiles>
<profile>
<id>server</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<build>
<plugins>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<id>jar-server</id>
<phase>package</phase>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<classifier>server</classifier>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
<profile>
<id>client</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<build>
<plugins>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<id>jar-client</id>
<phase>package</phase>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<classifier>client</classifier>
<excludes>
<exclude>**/server/**</exclude>
</excludes>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
</project>
Implementation module pom
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<parent>
<groupId>com.app</groupId>
<artifactId>myapp-parent</artifactId>
<version>1.1.0-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<groupId>com.app</groupId>
<artifactId>myapp-model</artifactId>
<version>1.1.0-SNAPSHOT</version>
<packaging>jar</packaging>
<name>myapp Model</name>
<properties>
<myapp-interfaces.classifier></myapp-interfaces.classifier>
<myapp-interfaces.version>1.1.0-SNAPSHOT</myapp-interfaces.version>
</properties>
<dependencies>
<dependency>
<groupId>com.app</groupId>
<artifactId>myapp-interfaces</artifactId>
<version>${myapp-interfaces.version}</version>
<classifier>${myapp-interfaces.classifier}</classifier>
</dependency>
[...]
</dependencies>
<profiles>
<profile>
<id>server</id>
<build>
<plugins>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<id>jar-server</id>
<phase>package</phase>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<classifier>server</classifier>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>com.app</groupId>
<artifactId>myapp-interfaces</artifactId>
<version>${myapp-interfaces.version}</version>
<classifier>${myapp-interfaces.classifier}</classifier>
</dependency>
</dependencies>
<properties>
<myapp-interfaces.classifier>server</myapp-interfaces.classifier>
</properties>
</profile>
<profile>
<id>client</id>
<build>
<plugins>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<id>jar-client</id>
<phase>package</phase>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<classifier>client</classifier>
<excludes>
<exclude>**/server/**</exclude>
<exclude>**/META-INF/services/**</exclude>
</excludes>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<properties>
<myapp-interfaces.classifier>client</myapp-interfaces.classifier>
</properties>
<dependencies>
<dependency>
<groupId>com.app</groupId>
<artifactId>myapp-interfaces</artifactId>
<version>${myapp-interfaces.version}</version>
<classifier>${myapp-interfaces.classifier}</classifier>
</dependency>
</dependencies>
</profile>
</profiles>
</project>
The problem with this solution is due to the fact that my client interface have some missing interfaces and maven throw a compilation error during the compile phase.
And if I use myapp-model and an other project I didn't not have dependency to the right myapp-interface.
I wonder if it's possible to build a jar and put a specific pom inside ?
For the Interfaces.
I change nothing and build the both interfaces.jar (client + server).
For the Model
I import the both jar as optional
<dependency>
<groupId>com.app</groupId>
<artifactId>myapp-interfaces</artifactId>
<version>${myapp-interfaces.version}</version>
<classifier>client</classifier>
<optional>true</optional>
</dependency>
<dependency>
<groupId>com.app</groupId>
<artifactId>myapp-interfaces</artifactId>
<version>${myapp-interfaces.version}</version>
<classifier>server</classifier>
<optional>true</optional>
</dependency>
With that I can build the both model's version without any error.
In my client application and server application
For each application I create the dependency to the right interfaces.jar and models.jar
We are attempting to re-factor our modularized maven building. We've introduced a property DEPLOYMENT_ENV which might be "prod", "dev", "staging", or what not. The mentality we had going in was that we could then define, say:
dev.jdbc.username = yoyodyne
dev.jdbc.password = 0verthruster
staging.jdb.username = cavaliers
staging.jdbc.password = 8thdim
Where this seems to break down is feeding maven plugin's configurations. For example, DBUnit needs a username. Semantically, the solution we had in mind looked like the below, however maven does not allow for recursive property definitions in this fashion:
<configuration>
<username>${${DEPLOYMENT_ENV}.jdbc.username}</username>
</configuration>
Any ideas for parameterizing maven builds, such that we can keep our big huge central list of property definitions?
Instead of different property names you can simply use same properties, but declare them in different profiles, either in pom.xml or in settings.xml
Could you be a little more specific about the issue you encounter? Do you have any error?
I already used this recursive property definition in one of my pom.xml, in a antrun plugin <configuration> and it works well:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.2</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
...
<ftp server="${my-ftp-url}" userid="${ftp-${appli}-${env}-username}" password="${ftp-${appli}-${env}-password}"
remotedir="${remoteDir}/sources" passive="yes">
<fileset dir="../target/">
<include name="*.tar.gz"/>
</fileset>
</ftp>
...
As you can see in this code snippet, I use the ${ftp-${appli}-${env}-username} property, where ${appli}, ${env} and ${ftp-xxx-yyy-username} are properties that come from command line or settings.xml.
Anyway, as suggested by Eugene Kuleshov, I would go for a set of <profiles> that only define some properties, using <properties> tags, or an external property file:
<build>
<plugins>
<!-- Properties loader -->
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0-alpha-1</version>
<executions>
<execution>
<phase>initialize</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
<configuration>
<files>
<file>${basedir}/${env-properties-file}</file>
</files>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
...
<profiles>
<!-- Development -->
<profile>
<id>dev</id>
<activation>
<activeByDefault>true</activeByDefault>
<property>
<name>env</name>
<value>dev</value>
</property>
</activation>
<properties>
<env-properties-file>dev-environment.properties</env-properties-file>
</properties>
</profile>
<!-- Homologation -->
<profile>
<id>hom</id>
<activation>
<activeByDefault>false</activeByDefault>
<property>
<name>env</name>
<value>hom</value>
</property>
</activation>
<properties>
<env-properties-file>homologation-environment.properties</env-properties-file>
</properties>
</profile>
...
I have a project that is using several profiles. Each profile uses following plugins:
maven-compiler-plugin
maven-resources-plugin
maven-antrun-plugin
maven-surefire-plugin
maven-war-plugin
The one marked in bold is however the only plugin where there is a difference between the profiles (different configuration files will be copied using the antrun plugin). The 4 other plugins are configured exactly the same for all profiles.
The question is now: is there some way to include these common plugins only once but still use them for all the profiles by default?
Something like:
<shared><plugin1><plugin2>...</shared>
<profile><plugin3></profile>
<profile><plugin3></profile>
...
thanks,
Stijn
If a plugin is used by all profile, simply define it in the <build> part :
<project>
...
<build>
<plugins>
Your shared plugins go here...
</plugins>
<profiles>
Definition of profiles...
</profiles>
</project>
This way, you will only define the antrun plugin in the profiles block.
Just include the common plugins in your build section:
<build>
<plugins>
<plugin>
<groupId>...</groupId>
<artifactId>plugin1</artifactId>
</plugin>
...
</plugins>
</build>
Then add the specific plugin in your profile:
<profiles>
<profile>
<id>...</id>
<build>
<plugins>
<plugin>
<groupId>...</groupId>
<artifactId>plugin3</artifactId>
</plugin>
</plugins>
</build>
</profile>
</profiles>
You can also configure the same plugin differently in different profiles this way:
<profiles>
<profile>
<id>profile1</id>
<build>
<plugins>
<plugin>
<groupId>...</groupId>
<artifactId>plugin1</artifactId>
<configuration>
<setting>value1</setting>
</configuration>
</plugin>
</plugins>
</build>
</profile>
<profile>
<id>profile2</id>
<build>
<plugins>
<plugin>
<groupId>...</groupId>
<artifactId>plugin1</artifactId>
<configuration>
<setting>value2</setting>
</configuration>
</plugin>
</plugins>
</build>
</profile>
</profiles>
I have a simple pom and added an ant-run to the compile but it only executes then when I do the following:
mvn install antrun:run
mvn install -- doesn't process the ant-run
mvn antrun:run -- doesn't process the ant-run
I thought that be linking the plugin to the lifecyce phase that the plugin would be executed when I try to achieve that phase. This is not what is happening.
Am I missing some nuance, do I need to have a profile which enables the plugin?
Thanks for the help (pom below)
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>my-app</name>
<url>http://maven.apache.org</url>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.3</version>
<executions>
<execution>
<id>antecho</id>
<phase>compile</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo message="Hello,world"/>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
</build>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
You've specified the plugin below the <pluginManagement> section. This means that this configuration will be used if the plugin is also declared directly under build/plugins, for example in a child POM.
To make it work in this instance remove the <pluginManagement> tags so that <plugins> is directly below <build> like this:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
...
</plugin>
</plugins>
</build>
You need to add a phase.
e.g.:
<executions>
<execution>
<id>xml2fastinfoset</id>
<phase>generate-sources</phase>
<goals>
<goal>xml2fastinfoset</goal>
</goals>
</execution>
</executions>
You might find this maven antrun example helpful.