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.
Common Environments
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 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 such as 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 create a default
profile in your settings.xml
Get Maven: The Definitive Guide now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
