Introduction to Build Profiles
6393 ワード
Introduction to build profiles
Maven 2.0 goes to great lengths to ensure that builds are portable. Among other things, this means allowing build configuration inside the POM, avoiding all filesystem references (in inheritance, dependencies, and other places), and leaning much more heavily on the local repository to store the metadata needed to make this possible.
However, sometimes portability is not entirely possible. Under certain conditions, plugins may need to be configured with local filesystem paths. Under other circumstances, a slightly different dependency set will be required, and the project's artifact name may need to be adjusted slightly. And at still other times, you may even need to include a whole plugin in the build lifecycle depending on the detected build environment.
To address these circumstances, Maven 2.0 introduces the concept of a build profile. Profiles are specified using a subset of the elements available in the POM itself (plus one extra section), and are triggered in any of a variety of ways. They modify the POM at build time, and are meant to be used in complementary sets to give equivalent-but-different parameters for a set of target environments (providing, for example, the path of the appserver root in the development, testing, and production environments). As such, profiles can easily lead to differing build results from different members of your team. However, used properly, profiles can be used while still preserving project portability. This will also minimize the use of -f option of maven which allows user to create another POM with different parameters or configuration to build which makes it more maintainable since it is runnning with one POM only.
Per Project- Defined in the POM itself (pom.xml). Per User- Defined in the Maven-settings (%USER_HOME%/.m2/settings.xml). Global- Defined in the global Maven-settings (%M2_HOME%/conf/settings.xml). Profile descriptor- a descriptor located in project basedir (profiles.xml) (unsupported in Maven 3.0: see Maven 3 compatibility notes )
A profile can be triggered/activated in several ways: Explicitly Through Maven settings Based on environment variables OS settings Present or missing files
Profiles can be explicitly specified using the -P CLI option.
This option takes an argument that is a comma-delimited list of profile-ids to use. When this option is specified, no profiles other than those specified in the option argument will be activated.
Profiles can be activated in the Maven settings, via the section. This section takes a list of elements, each containing a profile-id inside.
Profiles listed in the tag would be activated by default every time a project use it.
Profiles can be automatically triggered based on the detected state of the build environment. These triggers are specified via an section in the profile itself. Currently, this detection is limited to prefix-matching of the JDK version, the presence of a system property or the value of a system property. Here are some examples.
The following configuration will trigger the profile when the JDK's version starts with "1.4"(eg. "1.4.0_08", "1.4.2_07", "1.4"):
Ranges can also be used as of Maven 2.1 (refer to the Enforcer Version Range Syntax for more information). The following honours versions 1.3, 1.4 and 1.5.
Note: an upper bound such as ,1.5] is likely not to include most releases of 1.5, since they will have an additional "patch"release such as _05 that is not taken into consideration in the above range.
This next one will activate based on OS settings. See the Maven Enforcer Plugin for more details about OS values.
The profile below will activate the profile when the system property "debug"is specified with any value:
Introduction to Build Profiles
Maven 2.0 goes to great lengths to ensure that builds are portable. Among other things, this means allowing build configuration inside the POM, avoiding all filesystem references (in inheritance, dependencies, and other places), and leaning much more heavily on the local repository to store the metadata needed to make this possible.
However, sometimes portability is not entirely possible. Under certain conditions, plugins may need to be configured with local filesystem paths. Under other circumstances, a slightly different dependency set will be required, and the project's artifact name may need to be adjusted slightly. And at still other times, you may even need to include a whole plugin in the build lifecycle depending on the detected build environment.
To address these circumstances, Maven 2.0 introduces the concept of a build profile. Profiles are specified using a subset of the elements available in the POM itself (plus one extra section), and are triggered in any of a variety of ways. They modify the POM at build time, and are meant to be used in complementary sets to give equivalent-but-different parameters for a set of target environments (providing, for example, the path of the appserver root in the development, testing, and production environments). As such, profiles can easily lead to differing build results from different members of your team. However, used properly, profiles can be used while still preserving project portability. This will also minimize the use of -f option of maven which allows user to create another POM with different parameters or configuration to build which makes it more maintainable since it is runnning with one POM only.
What are the different types of profile? Where is each defined?
How can a profile be triggered? How does this vary according to the type of profile being used?
A profile can be triggered/activated in several ways:
Details on profile activation
Profiles can be explicitly specified using the -P CLI option.
This option takes an argument that is a comma-delimited list of profile-ids to use. When this option is specified, no profiles other than those specified in the option argument will be activated.
mvn groupId:artifactId:goal -P profile-1,profile-2Profiles can be activated in the Maven settings, via the
<settings>
...
<activeProfiles>
<activeProfile>profile-1</activeProfile>
</activeProfiles>
...
</settings>Profiles listed in the
Profiles can be automatically triggered based on the detected state of the build environment. These triggers are specified via an
The following configuration will trigger the profile when the JDK's version starts with "1.4"(eg. "1.4.0_08", "1.4.2_07", "1.4"):
<profiles>
<profile>
<activation>
<jdk>1.4</jdk>
</activation>
...
</profile>
</profiles>Ranges can also be used as of Maven 2.1 (refer to the Enforcer Version Range Syntax for more information). The following honours versions 1.3, 1.4 and 1.5.
<profiles>
<profile>
<activation>
<jdk>[1.3,1.6)</jdk>
</activation>
...
</profile>
</profiles>Note: an upper bound such as ,1.5] is likely not to include most releases of 1.5, since they will have an additional "patch"release such as _05 that is not taken into consideration in the above range.
This next one will activate based on OS settings. See the Maven Enforcer Plugin for more details about OS values.
<profiles>
<profile>
<activation>
<os>
<name>Windows XP</name>
<family>Windows</family>
<arch>x86</arch>
<version>5.1.2600</version>
</os>
</activation>
...
</profile>
</profiles>The profile below will activate the profile when the system property "debug"is specified with any value:
<profiles>