Activation of maven profile based on multiple properties - maven-2

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!

Related

Maven: Only want to run profile if doing a build on the parent pom

I'm using Maven 3.0.3. I have a project that inherits from a parent …
<modelVersion>4.0.0</modelVersion>
<groupId>com.myco.util.ant</groupId>
<artifactId>selenium-framework</artifactId>
<packaging>jar</packaging>
<name>Myco Selenium Utils</name>
<parent>
<groupId>com.nna</groupId>
<artifactId>parent</artifactId>
<version>1.2-SNAPSHOT</version>
<relativePath>../parent</relativePath>
</parent>
In my parent pom I have the below profile. However, I only want this profile to be active if someone is doing a build on the parent pom, as opposed to one of its children. Does anyone know how I can adjust the below so that it won't be activated if someone is doing a build of a child project?
<profile>
<id>deploy-snapshot</id>
<build>
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.6</version>
<executions>
<execution>
<phase>deploy</phase>
<configuration>
<target>
<condition property="is-release">
<not>
<contains string="${project.version}" substring="SNAPSHOT" />
</not>
</condition>
<fail if="is-release" message="You can only deploy snapshot versions of this project." />
</target>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
</profile>
Thanks, - Dave
You could try activating it by the presence/absence of a file or directory. You can find an example in the Sonatype Maven book. Note that there's a difference between "current working directory" and "${project.basedir}", and the differences are slightly different between Maven 2 and Maven 3, if that matters to you.
I had a similar situation, I wanted to run a profile in a subproject by default but not when build from the top level, and at the same time give the option to run it from the top project as well.
I used the user.dir property for that in combination of Ryan's reference.
in integration project's pom:
<profile>
<id>continuous-integration</id>
<!-- Two ways of activating this profile -->
<activation>
<!-- Run the build from the top with param -DfullTest -->
<property>
<name>fullTest</name>
</property>
<!-- Run the build from the integration directory -->
<file>
<missing>${user.dir}/integration</missing>
</file>
</activation>
...
<profile>
If needs to be disabled just change the <missing/> for a <exists/>.

Recursively defining maven properties

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

Building same project in Maven with different artifactid (based on JDK used)

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.

Maven: use common/shared plugins when working with multiple profiles

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>

Problems with maven output directory

I'm using almost same POM for both my projects, they are on the same workspace but they are not related at all, they are related however because in both I use spring and jboss. Here is the 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">
<modelVersion>4.0.0</modelVersion>
<groupId>com.springinaction.hello</groupId>
<artifactId>spring-in-action</artifactId>
<packaging>jar</packaging>
<version>0.0.1-SNAPSHOT</version>
<name>spring-in-action</name>
<url>http://maven.apache.org</url>
<properties>
<jboss.ome>C:\jboss-5.1.0.GA\server\default\deploy</jboss.ome>
<springversion>2.5.3</springversion>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
<version>${springversion}</version>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.14</version>
<scope>provided</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.0</version>
<configuration>
<warName>spring-book</warName>
<outputDirectory>${jboss.ome}</outputDirectory>
</configuration>
</plugin>
</plugins>
</build>
</project>
What I want to achieve with this POM is that I want to name my war when built spring-book.war and copy it to Jboss location I specified. Now in my first project this works it does exactly what I requested but in other it does not. I changed springversion and jboss home properties variable but everything remains the same, what can I do ? The project builds and all, everything is working perfectly just I don't want to copy everytime in my jboss dir and previously remove the old war, it takes about 20sec on each source code change its a lot
Problem spotted at this line:
<packaging>jar</packaging>
You're not using the right packaging, it should be:
<packaging>war</packaging>
After this change the war plugin should get called and things should work like in the other project :)
You could leave the output directory at its default, and use a profile instead with the maven jboss plugin. It has a hard-deploy target which copies your artifact to the deploy directory. If it's in a profile, you can activate it when (and only when) you want.
Moreover, with the antrun plugin, you can also delete the old war file before copying over the new one (this is useful when the war filename includes the version, but in your case may not be needed).
<profiles>
<profile>
<id>deploy</id>
<build>
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>remove-old-war</id>
<phase>prepare-package</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<delete>
<fileset dir="${jboss.ome}"
includes="*.war"/>
</delete>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jboss-maven-plugin</artifactId>
<executions>
<execution>
<id>redeploy-server</id>
<phase>pre-integration-test</phase>
<goals>
<goal>hard-deploy</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
You can then activate the profile with
mvn -Pdeploy install