Profile allows us to define a series of configuration information and then specify its activation conditions. So we can define multiple profiles,
Then each profile corresponds to different activation conditions and configuration information, so as to achieve the effect of using different configuration information in different environments.
For example, we can use one set of configuration information above JDK1.5 through profile definition, and another set of configuration information below JDK1.5;
Or sometimes we can use different configuration information through different operating systems, such as a set of information under windows,
Linux is another set of information, and so on. I will talk about the specific activation conditions later.
Profile definition location
We can define profiles in multiple places. Different definitions have different scopes.
- The profile configuration for a specific project can be defined in pom.xml of the project.
- For user specific profile configuration, we can define profile in the user’s settings.xml file.
The file is in the “. M2” directory under the user’s home directory.
- Global profile configuration. The global profile is defined in the “conf / settings. XML” file under the Maven installation directory
Information that can be defined in profile
When a profile is defined in settings.xml, it means that the profile is global, and it will work on all projects or all projects of a user.
Because it is global, only a relatively wide range of configuration information, such as remote warehouse, can be defined in settings.xml.
Some of the more detailed needs to be defined according to different projects need to be defined in pom.xml of the project.
Specifically, the information that can be defined in settings.xml includes < repositories >, < plugin repositories > and < Properties >.
The key value pairs defined in < Properties > can be used in pom.xml.
Profile is defined in pom.xml
Profiles defined in pom.xml can define more information. There are mainly the following:
<repositories> <puginRepositories> <dependencies> <pugins> <properties> <dependencyManagement> <distributionManagement>
There are also sub elements below the buid element, mainly including:
<defautGoa> <resources> <testResources> <finaName>
Profile activation mode
Activate with activebydefault settings
<profiles> <profile> <id>profileTest1</id> <properties> <hello>world</hello> </properties> <activation> <activeByDefault>true</activeByDefault> </activation> </profile> <profile> <id>profileTest2</id> <properties> <hello>andy</hello> </properties> </profile> </profiles>
We can specify the activation condition in the activation element of the profile. When the profile is not explicitly specified and the activebydefault is set to true,
This means that the profile is activated by default.
For example, when we call MVN package, profiletest1 above will be activated, but when we use MVN package – P profiletest2, profiletest2 will be activated, and profiletest1 will not be activated at this time.
Use activeprofiles in settings.xml to specify the active profile
<settings> ... <activeProfiles> <activeProfile>profile-1</activeProfile> </activeProfiles> ... </settings>
Activate a profile using the – P parameter display
Activate profile according to environment
Profiles can be automatically triggered based on the detected state of the build environment.
These triggers are specified via an <activation> 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.
View the profile currently active