indiWiz.com

Thanks to Arun Jeganath for making me understand Maven Profiles.

Often we are forced to specify different build parameters in different environments. In the ages of Make, these parameters used to be specified as environment variables. In the world of Maven, we have profiles.

Profiles: Introduction

A sample profile information:

  <profiles>

    <!-- DEV Profile (Default) -->
    <profile>
      <id>dev-profile</id>
      <activation>
        <property>
          <name>env</name>
          <value>dev</value>
        </property>
        <activeByDefault>true</activeByDefault> <!-- Note this -->
      </activation>
      <!-- Liferay Home in DEV -->
      <properties>
        <liferay-home>${user.home}/apps/liferay-portal-tomcat-6.0-5.1.2</liferay-home>
      </properties>
    </profile>

    <!-- TEST Profile -->
    <profile>
      <id>test-profile</id>
      <activation>
        <property>
          <name>env</name>
          <value>test</value>
        </property>
      </activation>
      <!-- Liferay Home in TEST -->
      <properties>
        <liferay-home>/opt/apps/liferay-portal-tomcat-6.0-5.1.2</liferay-home>
      </properties>
    </profile>
  </profiles>

Quick learning from the above example:

• There can be number of profiles defined.
• A profile can be marked as <activeByDefault>. This will enforce the configuration defined in the activated profile to take effect during build.
• To enable a specific profile during build, the value defined in XPath /profiles/profile/activation/property needs to be passed the Maven as System Property (in our case: -Denv=test).
• The property defined in the profile (liferay-home) can be referenced elsewhere in the pom.xml as ${liferay-home}.

Placing profile information

Profile information is generally placed in:

1. In the project POM itself.
2. Inside {user.home}/.m2/settings.xml.

In the first case (in this particular example), the deployment information is placed in the project’s POM. This, some might feel improper because the module/project build has hardcoded environment dependencies which might not work in other systems. The second option externalizes the platform specific build information. But a new developer checking out the project will not be aware of this external dependency causing his build to fail. Both these problems might be addressed using documentation: some projects have README and BUILD files explaining environment setup for build.

As we saw, both methods have advantages and disadvantages. Choose the method appropriate to your situation.

Parameters that can be overridden in profiles

Note: This list is shamelessly copied from the official Maven profiles guide. Refer to this guide for detailed information.

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