Build Profiles ( Maven profiles)

  • Do Note that Maven profiles were introduced as “build” profiles
  • Be careful to ensure your  builds are portable.
    While you learn maven profiles, any careless use of them in your project would break the portability.
  • Profiles are specified using a subset of the elements available in the POM itself (plus one extra section)
  • Profiles are triggered in any of a variety of ways.
  • They modify the POM at build time, and are meant to be used in complementary sets to give equivalent-but-different parameters for a set of target environments (providing, for example, the path of the appserver root in the development, testing, and production environments)

What are the different types of profile? Where is each defined?

How can a profile be triggered? How does this vary according to the type of profile being used?

A profile can be triggered/activated in several ways:

  • Explicitly (eg: mvn package -Pprofile1)
  • Through Maven settings
  • Based on environment variables (eg: mvn package -Denvironment=dev)
  • OS settings
  • Present or missing files

Details on profile activation

  • (1) 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(-P) is specified,

  1. the profile(s) specified in the option argument will be activated in addition to
  2. any profiles which are activated by their activation configuration or the <activeProfiles> section in settings.xml.mvn com.codinko:myproject:packageP profile1,profile2
  • (1.a) Profiles can be activated in the Maven settings,
    via the <activeProfiles> section. This section takes a list of <activeProfile> elements, each containing a profile-id inside.

<settings>
    <activeProfiles>
       <activeProfile>profile-1</activeProfile>
   </activeProfiles>

</settings>

 

More on  <activeProfiles>

  • Profiles listed in the <activeProfiles> tag would be activated by default every time a project use it.
  • (2) Profiles can be automatically triggered based on the detected state of the build environment.
    These triggers are specified via an <activation> section in the profile itself. Currently, this detection is limited to
  • (a) prefix-matching of the JDK version,
  • (b) the presence of a system property or
  • (c) the value of a system property.Here are some examples.

Triggering profiles

The following configuration will trigger the profile when the JDK’s version starts with “1.4” (eg. “1.4.0_08”, “1.4.2_07”, “1.4”):

<profiles>
 <profile>
 <activation>
       <jdk>1.4</jdk>
  </activation>

</profile>
</profiles>

Ranges

 

Ranges can also be used as of Maven 2.1.  The following honors versions 1.3, 1.4 and 1.5.

<profiles>
  <profile>
    <activation>
       <jdk>[1.3,1.6)</jdk>
    </activation>

</profile>
</profiles>

 

Note: an upper bound such as ,1.5] is likely not to include most releases of 1.5, since they will have an additional “patch” release such as _05 that is not taken into consideration in the above range.

Based on OS settings.

This next one will activate based on OS settings. See the Maven Enforcer Plugin for more details about OS values.

<profiles>
  <profile>
     <activation>
        <os>
         <name>Windows XP</name>
         <family>Windows</family>
         <arch>x86</arch>
         <version>5.1.2600</version>
        </os>
     </activation>
  …
</profile>
</profiles>

Based on whether a property value is defined or not

 

The profile below will be activated when the system property “debug” is specified with any value:

  • <profiles>
  • <profile>
  • <activation>
  • <property>
  • <name>debug</name>
  • </property>
  • </activation>
  • </profile>
  • </profiles>

The following profile will be activated when the system property “debug” is not defined at all:

  • <profiles>
  • <profile>
  • <activation>
  • <property>
  • <name>!debug</name>
  • </property>
  • </activation>
  • </profile>
  • </profiles>

The following profile will be activated when the system property “debug” is not defined, or is defined with a value which is not “true”.

  • <profiles>
  • <profile>
  • <activation>
  • <property>
  • <name>debug</name>
  • <value>!true</value>
  • </property>
  • </activation>
  • </profile>
  • </profiles>
To activate this you would type one of those on the command line:
  1. mvn groupId:artifactId:goal
  2. mvn groupId:artifactId:goal Ddebug=false

Based on value set for a system property

 

The next example will trigger the profile when the system property “environment” is specified with the value “test”:

  • <profiles>
  • <profile>
  • <activation>
  • <property>
  • <name>environment</name>
  • <value>test</value>
  • </property>
  • </activation>
  • </profile>
  • </profiles>
To activate this you would type this on the command line:
  1. mvn groupId:artifactId:goal Denvironment=test

As of Maven 3.0, profiles in the POM can also be activated based on properties from active profiles from the settings.xml.

Note: Environment variables like FOO are available as properties of the form env.FOO. Further note that environment variable names are normalized to all upper-case on Windows.

Based on whether a file is missing or not

This example will trigger the profile when the generated file target/generated-sources/axistools/wsdl2java/org/apache/maven is missing.

  1. <profiles>
  2. <profile>
  3. <activation>
  4. <file>
  5. <missing>target/generated-sources/axistools/wsdl2java/org/apache/maven</missing>
  6. </file>
  7. </activation>
  8. </profile>
  9. </profiles>

As of Maven 2.0.9,

  • the tags <exists> and <missing> could be interpolated.
  • Supported variables are system properties like ${user.home} and environment variables like ${env.HOME}. Please note that properties and values defined in the POM itself are not available for interpolation here, e.g. the above example activator cannot use ${project.build.directory} but needs to hard-code the path target.

Activating profile by default

Profiles can also be active by default using a configuration like the following:

<profiles>
<profile>
     <id>profile-1</id>
 <activation>
        <activeByDefault>true</activeByDefault>
    </activation>

</profile>
</profiles>

 

This profile will automatically be active for all builds unless another profile in the same POM is activated using one of the previously described methods. All profiles that are active by default are automatically deactivated when a profile in the POM is activated on the command line or through its activation config.

Deactivating a profile

Starting with Maven 2.0.10, one or more profiles can be deactivated using the command line by prefixing their identifier with either the character ‘!’ or ‘-‘ as shown below:

  1. mvn groupId:artifactId:goal P!profile1,!profile2

This can be used to deactivate profiles marked as activeByDefault or profiles that would otherwise be activated through their activation config.

 

Which areas of a POM can be customized by each type of profile?

Depending on where you choose to configure your profile, you will have access to varying POM configuration options.

1. Profiles in external files

  • Profiles specified in external files (i.e in settings.xml or profiles.xml) are not portable in the strictest sense.
  • Therefore, you will only be able to modify the <repositories> and <pluginRepositories> sections, plus an extra <properties> section.

2. Profiles in POMs

Profiles specified in the POM can modify the following POM elements:

  • <repositories>
  • <pluginRepositories>
  • <dependencies>
  • <plugins>
  • <properties> (not actually available in the main POM, but used behind the scenes)
  • <modules>
  • <reporting>
  • <dependencyManagement>
  • <distributionManagement>
  • a subset of the <build> element, which consists of:
    • <defaultGoal>
    • <resources>
    • <testResources>
    • <finalName>

POM elements outside <profiles> ?

  • External files such as settings.xml and profiles.xml also does not support elements outside the POM-profiles . This is done to retain the build portability.

Code examples to usage of profiles in pom.xml

  1. (a) Complete code example-1 to usage of profiles in pom.xml

source file: https://github.com/codinko/mavenprofiles/blob/master/pom.xml

1 (b)Another code example-1 to usage of profiles in pom.xml

https:// www.tutorialspoint.com/maven/maven_build_profiles.htm

Important: Why you should use Maven profiles carefully? What are the steps to be taken care so you don’t break your project build and portability?

Read this:

  1. Read section “Profile Pitfalls ” here : https://maven.apache.org/guides/introduction/introduction-to-profiles.html
  2. Read Maven profile best practices here :
    https:// dzone.com/articles/maven-profile-best-practices
  3. See this example which is a perfect example that shows a scenario where  maven profile is supported, but should not be used. Instead you should use some spring properties. https:// www.mkyong.com/maven/maven-profiles-example/
References:
  1. https:// maven.apache.org/guides/introduction/introduction-to-profiles.html
  2. https:// www.tutorialspoint.com/maven/maven_build_profiles.htm
  3. https:// www.mkyong.com/maven/maven-profiles-example/
  4. https:// dzone.com/articles/maven-profile-best-practices