Define different value per profile for same Maven property - maven

I'm facing a problem with maven property per profiles. I have two profiles, each one has the same property 'prop.key' with different values. When I call mvn clean package -PA -PB or mvn clean package -PB -PA both are using the same value 'B-1.0-SNAPSHOT'. I'm using maven 3.0.4.
Below my POM :
<?xml version="1.0" encoding="UTF-8"?>
<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.test.module</groupId>
<artifactId>test-module</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>pom</packaging>
<properties>
<prop.key>UNKNOWN</prop.key>
</properties>
<profiles>
<profile>
<id>A</id>
<properties>
<prop.key>A-${project.version}</prop.key>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.2</version>
<executions>
<execution>
<id>A</id>
<phase>package</phase>
<configuration>
<tasks name="a" description="a-desc">
<echo message="RUN A = ${prop.key}" level="info"/>
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
<profile>
<id>B</id>
<properties>
<prop.key>B-${project.version}</prop.key>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.2</version>
<executions>
<execution>
<id>B</id>
<phase>package</phase>
<configuration>
<tasks name="b" description="b-desc">
<echo message="RUN B = ${prop.key}" level="info"/>
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
</project>
I have found 'similar topic' but with opposite result!
Is it a bug or a feature of maven?

You can write
mvn package -PA,B
for short.
The result is the same:
[echo] RUN A = B-1.0-SNAPSHOT and
[echo] RUN B = B-1.0-SNAPSHOT
This is the correct behaviour of maven.
One property can only have one specific value per run. You can overwrite a "default value" with a version in a profile. But if you redefine it in two profiles and activate both, one of the profiles "wins".
It is not possible to have one value per profile for one and the same property. Profiles do not have their own variable scope. Properties are always global.

I would think you get this behavior because last parameter for profile gets picked.
Try
mvn clean package -PA,B
See Maven introduction to profiles.
Profiles can be explicitly specified using the -P CLI option.
This option takes an argument that is a comma-delimited list of
profile-ids to use. When this option is specified, no profiles other
than those specified in the option argument will be activated.

When you run mvn package -PA,B, maven will read both profiles A and B, and the properties from later one in the pom.xml file will take precedence (B is defined below A in pom.xml), result in <prop.key>B-${project.version}</prop.key> will be used.

Related

Parent POM is not flattened when deployed to Nexus

I have a multi-module Maven project where the project version is set via the revision variable.
<groupId>pricing</groupId>
<artifactId>pricing-backend-pom</artifactId>
<version>${revision}</version>
<packaging>pom</packaging>
<properties>
<revision>3.0.7</revision>
</properties>
<modules>
<module>pricing-backend-war</module>
<module>pricing-backend-model</module>
<module>pricing-backend-client</module>
</modules>
<build>
<plugins>
<!-- flatten before deploy. removes $revision -->
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>flatten-maven-plugin</artifactId>
<version>1.2.7</version>
<configuration>
</configuration>
<executions>
<!-- enable flattening -->
<execution>
<id>flatten</id>
<phase>process-resources</phase>
<goals>
<goal>flatten</goal>
</goals>
</execution>
<!-- ensure proper cleanup -->
<execution>
<id>flatten.clean</id>
<phase>clean</phase>
<goals>
<goal>clean</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
During the Gitlab build, the project is deployed to a Nexus repository. Each module and the parent appear in Nexus but only the modules appear to be flattened. The module POMs each contain <version>3.0.7</version> but the parent POM still contains <version>${revision}</version>.
I find it difficult to understand why the parent is deployed differently to the modules. I have checked the build logs but cannot see any indication that the parent is handled in a different way.
The parent POM taken from Nexus:
<groupId>pricing</groupId>
<artifactId>pricing-backend-pom</artifactId>
<version>${revision}</version>
<packaging>pom</packaging>
<properties>
<revision>3.0.7</revision>
...
A module POM:
<groupId>pricing</groupId>
<artifactId>pricing-backend-client</artifactId>
<version>3.0.7</version>
<dependencies>
...
The build applies the required version:
$ echo New version= ${MAVEN_VERSION}
New version= -Drevision=3.0.7-SNAPSHOT
$ mvn $MAVEN_CLI_OPTS ${MAVEN_VERSION} deploy -DskipTests
The pom file to be installed can be explicitly set:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<version>2.4</version>
<configuration>
<pomFile>.flattened-pom.xml</pomFile>
</configuration>
</plugin>
Above, flatten-maven-plugin has been previously invoked to produce .flattened-pom.xml
If you do a test by adding -Drevision=<someVersion> to the command line, does that produce correct results in Nexus?
I suspect it will.
Properties are interpolated very early in the process. When the command first runs, ${revision} is undefined, so Maven leaves it as-is. The flatten then calculates ${revision}, but that only applies from the time the plugin runs and later.
You can try researching "late binding" properties (they start with '#' instead of '$') but I'm not sure if those work in top level fields like the GAV coords.

Properties defined in the properties section of the POM are not seen in external ant build file

I'm using maven-antrun-plugin in my pom.xml with external ant file.
It's said in plugin's document:
All of the properties available to Maven are also available in the
target configuration. However, you may want to call an external Ant
build script using the ant task. To avoid name conflicts, only a
subset of the properties are passed to the external Ant build. These
include all properties defined in the properties section of the POM.
It also includes prefixed versions of some of the commonly used Maven
properties.
So here's my pom, where I define "test.prop" property:
<?xml version="1.0" encoding="UTF-8"?>
<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>testant</groupId>
<artifactId>testant</artifactId>
<version>1.0-SNAPSHOT</version>
<properties>
<test.prop>TestPropValue</test.prop>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<dependencies>
<dependency>
<groupId>ant</groupId>
<artifactId>optional</artifactId>
<version>1.5.4</version>
</dependency>
</dependencies>
<executions>
<execution>
<id>generate-index-properties</id>
<phase>install</phase>
<configuration>
<tasks>
<!--<property name="test.prop" value="${test.prop}"/>-->
<ant antfile="build.xml">
<target name="echo-prop"/>
</ant>
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
And just trying to echo this property in build.xml:
<project default="test">
<target name="echo-prop">
<echo>${test.prop}</echo>
</target>
</project>
This is what I get:
echo-prop:
[echo] ${test.prop}
So property is not resolved as it should, according to the doc.
And it works fine only in case if I uncomment line with explicit property declaration under "tasks" tag.
Could you please help me in understanding, what am I doing wrong?
Thank you!
You should specify a version for the antrun-plugin:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.8</version><!--$NO-MVN-MAN-VER$-->
(...)
</plugin>
ant by default passes all properties of the parent to an underlying "ant"-call. Unless you define inheritAll=false, all properties are passed.
In this case, you should have a look at the effective pom. There a very ancient version of the antrun-plugin is defined.
As soon as you switch to a recent one, the example code works.

Duplication in maven: are profiles additive to project, or do they replace declared items?

Provided you have the following defined in your POM.xml:
<project>
<!-- ... -->
<build>
<plugins>
<plugin>
<artifactId>plugin-X</artifactId>
<!-- plugin config -->
</plugin>
<plugins>
</build>
<profiles>
<profile>
<id>foo</id>
<build>
<plugins>
<plugin>
<artifactId>plugin-X</artifactId>
<!-- plugin config -->
</plugin>
<plugins>
</build>
<profile>
</profiles>
</project>
If the plugin config for plugin-X is exactly the same for profile foo as it is for a build without a selected profile, do you have to redeclare the plugin at all on the profile level? If so, do you also have to redeclare all config settings for it?
If you declared plugin-Y in project.profile.build.plugins instead of plugin-X (but left it declared on the project level), which plugins would be run when you run mvn -P foo? Only plugin-Y, or also plugin-X?
More generally speaking, are profiles additive to what is declared on the project level, or do they override it? (If they are additive, how do you "remove" entities that were declared on a project level when you run a build profile and don't want them for that specific profile?)
I know profile configuration gets inherited from parent pom files ("from either the build/plugins or pluginManagement sections of the parent") with options "merge", "append", and "override". I think what I really want to know is: how does maven behave when the same/similar information is defined on the project and profile levels in the same pom file...
This isn't a full answer, but another piece of the puzzle - in addition to my earlier comments, and maven's Guide to Configuring Plug-ins.
Given the following pom.xml file:
</profiles>
<properties>
<foo>main</foo>
<bar>main</bar>
</properties>
<build>
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<phase>validate</phase>
<configuration>
<target>
<echo>${foo}</echo>
<echo>${bar}</echo>
<echo>${baz}</echo>
</target>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<profiles>
<profile>
<id>p</id>
<properties>
<bar>prof</bar>
<baz>prof</baz>
</properties>
</profile>
</profiles>
</project>
When I run mvn validate, I get the following output:
[echo] main
[echo] main
[echo] ${baz}
Running mvn validate -P p however yields:
[echo] main
[echo] prof
[echo] prof
That means that properties at least are merged, appending new items and replacing those that are redefined.
Also, if I add another plugin to the profile (such as surefire), it will execute when running the profile with mvn <phase> -P p, so the profile inherits antrun and adds surefire. Plugin re-definitions however replace the original; adding
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<phase>validate</phase>
<configuration>
<target>
<echo>Tada!</echo>
</target>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
only prints Tada!, but no longer the original antrun output (even when changing the new addition's phase to initialize. Adding <inherited>true</inherited> to any of the two plugin definitions doesn't make a difference. The behaviour might be plugin-specific, though.

Can I use property file in maven pom.xml for flyway configuration

<plugin>
<groupId>com.googlecode.flyway</groupId>
<artifactId>flyway-maven-plugin</artifactId>
<version>1.7</version>
<configuration>
<driver>com.mysql.jdbc.Driver</driver>
<url>jdbc:mysql://127.0.0.1:3306/db_abc</url>
<user>db_user</user>
<sqlMigrationPrefix>V</sqlMigrationPrefix>
</configuration>
</plugin>
I don't want to mention driver, url and user here. I already have a abc.property on src/main/resources. How can use that file here?
Have a look at the properties-maven-plugin. It allows you to read properties from a file to then use them in your pom.
Add the following plugin defintion:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0.0</version>
<executions>
<execution>
<phase>initialize</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
<configuration>
<files>
<file>src/main/resources/abc.properties</file>
</files>
</configuration>
</execution>
</executions>
</plugin>
If abc.properties contains:
jdbc.driver = com.mysql.jdbc.Driver
jdbc.url = jdbc:mysql://127.0.0.1:3306/db_ab
jdbc.user = db_user
You can then use the properties as follows:
<!-- language: xml -->
<driver>${jdbc.driver}</driver>
<url>${jdbc.url}</url>
<user>${jdbc.user}</user>
in version 3.0 you have to use configFile like :
<configFile>src/main/resources/db/config/flyway.properties</configFile>
In my opinion, the best and the most flexible approach is to:
a) use profiles and filtering - keep all configuration properties for specific profile (development, test, etc.), e.g. in development.properties:
jdbc.url=jdbc:mysql://127.0.0.1:3306/testdb?useSSL=false
jdbc.user=testuser
jdbc.password=testpass
jdbc.driver=com.mysql.jdbc.Driver
Then, in your pom file (possibly in root pom) define a profile, e.g:
...
<profiles>
<profile>
<id>development</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<build>
<filters>
<filter>../filters/development.properties</filter>
</filters>
</build>
...
here you can see that development profile is activated by default. If you want to use another profile set it with
-p [profile-id]
b) set flyway.properties with filtered values - your flyway.properties should sit e.g. in src/main/resources and the values should be used from the parameters defined in the profile properties file:
flyway.driver = ${jdbc.driver}
flyway.url = ${jdbc.url}
flyway.user = ${jdbc.user}
flyway.password = ${jdbc.password}
c) reference flyway.properties from build directory - use simple plugin configuration (I really like clean poms):
...
<build>
<resources>
<!-- This way we instruct maven to inject values from filters into the resources -->
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
<plugins>
<plugin>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-maven-plugin</artifactId>
<configuration>
<configFile>${project.build.directory}/classes/flyway.properties</configFile>
<locations>
<location>classpath:migration/mysql</location>
</locations>
</configuration>
</plugin>
</plugins>
</build>
...
Don't forget to enable filtering in resources as shown in many examples here. My flyway-maven-plugin version is 3.2.1 and it is managed in pluginManagement in parent pom, therefore version is not visible here. I also use explicit sql scripts with locations configuration.
There are several ways to deal with this. One approach is to do it the other way around.
That means that the properties to use are saved as properties inside the pom.xml and that the file abc.properties only has placeholders that will be filled in at build time.
I will show you how it can be configured.
This is what the pom.xml will look like:
<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.stackoverflow</groupId>
<artifactId>Q12619446</artifactId>
<version>1.0-SNAPSHOT</version>
<name>${project.artifactId}-${project.version}</name>
<properties>
<jdbc.driver>com.mysql.jdbc.Driver</jdbc.driver>
<jdbc.url>jdbc:mysql://127.0.0.1:3306/db_abc</jdbc.url>
<jdbc.user>db_user</jdbc.user>
</properties>
<build>
<plugins>
<plugin>
<groupId>com.googlecode.flyway</groupId>
<artifactId>flyway-maven-plugin</artifactId>
<version>1.7</version>
<configuration>
<driver>${jdbc.driver}</driver>
<url>${jdbc.url}</url>
<user>${jdbc.user}</user>
</configuration>
</plugin>
</plugins>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
</build>
</project>
And this will be your src/main/resources/abc.properties (use the key names of your choice):
jdbcDriver = ${jdbc.driver}
jdbcUrl = ${jdbc.url}
jdbcUser = ${jdbc.user}
After the build the target/classes/abc.properties will look like this:
jdbcDriver = com.mysql.jdbc.Driver
jdbcUrl = jdbc:mysql://127.0.0.1:3306/db_abc
jdbcUser = db_user
As stated this is only one of several ways to do it. It might not suit your exact needs but it could.
Garry,
there is one more way not to place database connection parameters to your pom-file. In particular, one can add them to settings.xml file in .m2 sub-folder of the user's folder [1]. The benefit is that the db paraneters do not live in the project folder and are not transmitted to the repository, so each developer may use her own settings.
The example of the settings file could look like the example below.
<?xml version="1.0" encoding="UTF-8"?>
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
<profiles>
<profile>
<id>fw</id>
<properties>
<flyway.url>jdbc:oracle:thin:#//localhost:1521/xe</flyway.url>
<flyway.user>Your login</flyway.user>
<flyway.password>Your password</flyway.password>
</properties>
</profile>
</profiles>
<activeProfiles>
<activeProfile>fw</activeProfile>
</activeProfiles>
</settings>
After that your can modify your pom-file according to the following snippet.
<?xml version="1.0"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<modelVersion>4.0.0</modelVersion>
...
<dependencies>
...
</dependencies>
<profiles>
<profile>
<id>fw</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-maven-plugin</artifactId>
<version>3.2.1</version>
<configuration>
<url>${flyway.url}</url>
<user>${flyway.user}</user>
<password>${flyway.password}</password>
</configuration>
<dependencies>
<dependency>
<groupId>com.oracle</groupId>
<artifactId>ojdbc7</artifactId>
<version>12.1.0.1.0</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
</profile>
</profiles>
</project>
In the example above Oracle's driver is used, but you can replace it with the required one.
To print current settings execute the following.
mvn help:effective-settings
In version 3.x you have configFile option
By default- flyway.properties in the same directory as the project POM.
You can add external property file in configuration section of pom or can be pass when running maven goal example-
command line-
mvn <goal> -Dflyway.configFile=myConfig.properties
Pom file-
<plugin>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-maven-plugin</artifactId>
<version>3.2.1</version>
<configuration>
<driver/>
<url/>
<user/>
<password/>
<baselineVersion>1.0</baselineVersion>
<baselineDescription>Base Migration</baselineDescription>
<skip>false</skip>
<configFile>myConfig.properties</configFile>
</configuration>
</plugin>

How to identify and set a missing environment property in Maven?

I have my build set-up so that I pass in my variable via the command line:
mvn clean install -DsomeVariable=data
In my pom I have:
<someTag>${someVariable}</someTag>
This works fine, but I would like to identify if someVariable is not specified on the command line, and then default it so that my script can continue.
Can this be done in Maven?
You can specify default property value in the properties section of your POM file:
<properties>
<someVariable>myVariable</someVariable>
</properties>
If you want to make sure that the property value is ALWAYS supplied on a command line, then you can use maven-enforcer-plugin.
Here is a link that shows how to enforce system property presence -> http://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
I'll just copy the XML verbatim here in case the above link goes bad.
<project>
[...]
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.0.1</version>
<executions>
<execution>
<id>enforce-property</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<requireProperty>
<property>basedir</property>
<message>You must have a basedir!</message>
<regex>\d</regex>
<regexMessage>You must have a digit in your baseDir!</regexMessage>
</requireProperty>
<requireProperty>
<property>project.version</property>
<message>"Project version must be specified."</message>
<regex>(\d|-SNAPSHOT)$</regex>
<regexMessage>"Project version must end in a number or -SNAPSHOT."</regexMessage>
</requireProperty>
</rules>
<fail>true</fail>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
[...]
</project>
You can specify the default value as
<properties>
<someTag>defaultValue</someTag>
</properties>
When you run maven command, you can override that value like this
mvn clean package -DsomeTag=newSpecificValue
You can use profiles instead, but you'll need a profile for each
variable.
<profile>
<id>default-value-1</id>
<activation>
<activeByDefault>false</activeByDefault>
<property>
<name>!someVariable</name>
</property>
</activation>
<properties>
<someVariable>DEFAULT-VALUE</someVariable>
</properties>
</profile>

Resources