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>

I was surprised to find a major new release of Maven. It seems that Maven 2.1.0 suffered from a major bug due to which releases could not be done. A quick overview of this bug and other feature improvements are discussed in this blog.

When using Maven from commandline, use this command:

If you are using Netbeans 6.7, you can generate a much more visual graph:

For bringing up this graph, just right click on the project and select Show Dependency Graph.

The screenshots above show the dependency graph for my project WizTools.org RESTClient.

My favorite project and build management tool, Maven, has been updated. View release notes for the list of bug fixes and feature improvements.