Profiles can encourage build portability. If your build needs subtle customizations to work on different platforms or if you need your build to produce different results for different target platforms, project profiles increase build portability. Settings profiles generally decrease build portability by adding extra-project information that must be communicated from developer to developer. The following sections provide some guidelines and some ideas for applying Maven profiles to your project.
One of the core motivations for Maven project profiles was
to provide for environment-specific configuration settings. In a
development environment, you might want to produce bytecode with debug
information and you might want to configure your system to use a
development database instance. In a production environment you might
want to produce a signed JAR and configure the system to use a
production database. In this chapter, we defined a number of
environments with identifiers like dev and
prod. A simpler way to do this would be to define
profiles that are activated by environment properties and to use these
common environment properties across all of your projects.
For example, if every project had a development
profile activated by a property named
environment.type having a value of
dev, and if those same projects had a
production profile activated by a property named
environment.type having a value of
prod, you could simply pass in the appropriate
property value on the command-line to ensure that your builds target the
correct environment. You can then use this property to activate profiles
defined in a project's pom.xml as follows. Let's
take a look at how a project's pom.xml would define
a profile activated by environment.type having the
value dev.
Example 5.6. Project Profile Activated by setting environment.type to 'dev'
<project>
...
<profiles>
<profile>
<id>development</id>
<activation>
<activeByDefault>true</activeByDefault>
<property>
<name>environment.type</name>
<value>dev</value>
</property>
</activation>
<properties>
<database.driverClassName>com.mysql.jdbc.Driver</database.driverClassName>
<database.url>
jdbc:mysql://localhost:3306/app_dev
</database.url>
<database.user>development_user</database.user>
<database.password>development_password</database.password>
</properties>
</profile>
<profile>
<id>production</id>
<activation>
<property>
<name>environment.type</name>
<value>prod</value>
</property>
</activation>
<properties>
<database.driverClassName>com.mysql.jdbc.Driver</database.driverClassName>
<database.url>jdbc:mysql://master01:3306,slave01:3306/app_prod</database.url>
<database.user>prod_user</database.user>
</properties>
</profile>
</profiles>
</project>
This project defines some properties like
database.url and database.user
which might be used to configure another Maven plugin configured in the
pom.xml. There are plugins available that can
manipulate the database, run SQL, and plugins like the Maven Hibernate3
plugin which can generate annotated model objects for use in persistence
frameworks. A few of these plugins, can be configured in a
pom.xml using these properties. These properties
could also be used to filter resources. If we needed to target the
development environment, we would just run the following command:
~/examples/profiles $ mvn install
Because the development profile is active by default, and because there are no other profiles activated, running mvn help:active-profiles will show that the development profile is active. Now, the activeByDefault option will only work if no other profiles are active. If you wanted to be sure that the development profile would be active for a given build, you could explicitly pass in the environment.type variable as follows:
~/examples/profiles $ mvn install -Denvironment.type=dev
Alternatively, if we need to activate the production profile, we could always run Maven with:
~/examples/profiles $ mvn install -Denvironment.type=prod
To test which profiles are active for a given build, use mvn help:active-profiles.
