Maven: The Complete Reference - 5.5. Tips and Tricks |
|
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 For example, if every project had a 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 ~/examples/profiles $ mvn install Because the development profile is active by default, and because
there are no other profiles activated, running ~/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 This best practice builds upon the previous section. In
Project Profile Activated by setting environment.type to dev, the production profile does not contain
the Storing Secrets in a User-specific Settings Profile. <settings> <profiles> <profile> <activeByDefault>true</activeByDefault> <properties> <environment.type>prod</environment.type> <database.password>m1ss10nimp0ss1bl3</database.password> </properties> </profile> </profiles> </settings>
This user has defined a default profile which sets the
NoteSecrets usually conflict with wide portability, but this makes sense. You wouldn’t want to share your secrets openly. Let’s assume that you have a library or a project that produces platform-specific customizations. Even though Java is platform-neutral, there are times when you might need to write some code that invokes platform-specific native code. Another possibility is that you’ve written some C code which is compiled by the Maven Native plugin and you want to produce a qualified artifact depending on the build platform. You can set a classifier with the Maven Assembly plugin or with the Maven Jar plugin. The following pom.xml produces a qualified artifact using profiles which are activated by Operating System parameters. For more information about the Maven Assembly plugin, see Chapter 8, Maven Assemblies. Qualifying Artifacts with Platform Activated Project Profiles. <project> ... <profiles> <profile> <id>windows</id> <activation> <os> <family>windows</family> </os> </activation> <build> <plugins> <plugin> <artifactId>maven-jar-plugin</artifactId> <configuration> <classifier>win</classifier> </configuration> </plugin> </plugins> </build> </profile> <profile> <id>linux</id> <activation> <os> <family>unix</family> </os> </activation> <build> <plugins> <plugin> <artifactId>maven-jar-plugin</artifactId> <configuration> <classifier>linux</classifier> </configuration> </plugin> </plugins> </build> </profile> </profiles> </project>
If the Operating System is in the Windows family, this pom.xml qualifies the JAR artifact with "-win". If the Operating System is in the Unix family, the artifact is qualified with "-linux". This pom.xml successfully adds the qualifiers to the artifacts, but it is more verbose than it need to be due to the redundant configuration of the Maven Jar plugin in both profiles. This example could be rewritten to use variable substitution to minimize redundancy as follows: Qualifying Artifacts with Platform Activated Project Profiles and Variable Substitution. <project> ... <build> <plugins> <plugin> <artifactId>maven-jar-plugin</artifactId> <configuration> <classifier>${envClassifier}</classifier> </configuration> </plugin> </plugins> </build> ... <profiles> <profile> <id>windows</id> <activation> <os> <family>windows</family> </os> </activation> <properties> <envClassifier>win</envClassifier> </properties> </profile> <profile> <id>linux</id> <activation> <os> <family>unix</family> </os> </activation> <properties> <envClassifier>linux</envClassifier> </properties> </profile> </profiles> </project>
In this pom.xml, each profile doesn’t need to include a Depending on a Qualified Artifact. <dependency> <groupId>com.mycompany</groupId> <artifactId>my-project</artifactId> <version>1.0</version> <classifier>linux</classifier> </dependency>
|