Question

I am using two profiles: development and production.

Development should be active on default; production should be used when I am releasing.

In my pom.xml I have:

[...]
<plugin>
<artifactId>maven-release-plugin</artifactId>
<version>2.0-beta-9</version>
<configuration>
  <useReleaseProfile>false</useReleaseProfile>
  <goals>deploy</goals>
  <arguments>-Pproduction</arguments>
</configuration>
</plugin>
[...]
<profiles>
  <profile>
    <id>production</id>
    <properties>
      <profile.name>production</profile.name>
    </properties>
    [...]
  </profile>
  <profile>
    <id>development</id>
    <activation>
      <activeByDefault>true</activeByDefault>
    </activation>
    <properties>
    <profile.name>development</profile.name>
    </properties>
       [...]
  </profile>
[...]

It just does not work.
useReleaseProfiles doesn’t work either:
http://jira.codehaus.org/browse/MRELEASE-459

The development profile should be always active but not when running mvn release:perform.
How do you achieve this?

[UPDATE]:
I have seen with the debug flag that my production profile is used, but development profile is used too, because it is activeByDefault. This cant be overridden by the releaseProfile argument. It would be nice to force the release plugin to use only the “production” profile.

Answer 1

The maven-release-plugin documentation encourages using the releaseProfiles configuration parameter to automatically invoke profiles during the release process.

This is a better approach than manually invoking release profiles from the command-line. One reason, is because the profiles used in the release will be documented in the pom.xml and stored with the tagged code. This makes the build process easier to understand and easier to repeat later, exactly the same way the project was originally released.

If using maven-release-plugin older than 2.4 see this bug preventing use of the above mentioned parameter.

Be aware that in case of a multi-module project you’ll have to put the “releaseProfiles” configuration in the root pom! See also this issue for more information about that.