Building a project through Maven is the choice of more and more people. I also joined the fun and built a project with maven. the question below
1. Ordinary WEB projects are built with maven, but do not use the profiles.xml file to configure parameters. Such a project can be deployed in the following ways:
Direct mvn clean package -DskipTests, package,
1) Then you can copy the war package to the Webapp directory under the tomcat directory
2) Modify the server.xml file in the conf directory in the tomcat directory, and add the following sentence between the Host tags:
<Context docBase="D:\IdeaProjects\Test\example\example-web\target\example- web" reloadable="false" path=""/>
2. Use profiles.xml to configure the default parameters, and these parameters are used in the web configuration file. At this time, when using the command package, you must specify which profiles id you want to use to assemble your project. The command is as follows mvn clean package -P development , where -p refers to which profiles id to enable. Then the following method of deploying to tomcat is the same as the above
Using maven, an IDE tool, Intellij IDEA, is recommended. He can specify the profiles id directly through the view.
Let's turn to an article about profile
Profiles is a key term in maven: profiles are used to define some environmental variations used in the build lifecycle, profiles can be set to activate different profiles in different environments (for example: different OS activates different profiles, different profiles JVM activates different profiles, different databases activate different profiles, etc.).
Define Profiles
You can define profiles in 4 places:
1. %M2_HOME%/conf/settings.xml, which are profiles for all users of this computer, and global profiles, which will affect all maven project builds
2. <your -home-directory>/.m2/settings.xml, which are profiles for per user, user-level profiles, which will affect all maven project builds of the current user
3. Defined in the pom.xml file, this It is only the profiles for this project, it is the project-level profiles
4, profiles.xml, which is in the same directory as pom.xml, and is also the project-level profiles. The purpose of using profiles.xml is to change the settings of the profiles from the pom.xml Extract the settings from .xml.
Among the profiles defined in these four places, profiles with a narrower scope will cover profiles with a wider scope. That is: profiles defined in pom.xml will override profiles.xml, profiles.xml will override <your-home-directory>/.m2/settings.xml, <your-home-directory>/.m2/settings .xml will overwrite %M2_HOME%/conf/settings.xml.
But please note: the profiles set in pom.xml are the most recommended, because pom.xml will be deployed to the repository, so the profiles in pom.xml will be available for subsequent builds originating from the repository or as transitive dependencies . The profiles defined in settings.xml and profiles.xml will not be deployed to the repository, there are many restrictions, therefore, only the following profiles can be defined in settings.xml and profiles.xml:
repositories
pluginRepositories
properties
Other types of profiles Must be defined in pom.xml (the above 3 profiles can also be defined in pom.xml).
The profiles that Pom.xml can define include:
<repositories>
<pluginRepositories>
<dependencies>
<plugins>
<properties> (not actually available in the main POM, but used behind the scenes)
<modules>
<reporting>
<dependencyManagement>
<distributionManagement>
a subset of the <build> element, which consists of:
<defaultGoal>
<resources>
< testResources>
<finalName>
2. Activating Profiles
There are several ways to activate profiles:
Explicitly
Through Maven settings
Based on environment variables
OS settings
Present or missing files
1) Display activation profiles through the -P parameter of the mvn command, the parameter value is profile id list (connected with commas). For example:
mvn groupId:artifactId:goal -P profileId-1,profileId-2
2) Activated by setting the <activeProfiles> element in settings.xml (of course <profiles> must also be defined in settings.xml)
<settings>
...
<profiles>
<profile>
<id>profile1</id>
. ..
</profile>
</profiles>
<activeProfiles>
<activeProfile>profile-1</activeProfile>
</activeProfiles>
...
</settings>
The profiles list listed in <activeProfiles> will be executed for each project Activated
3) Profiles can also be automatically activated based on the detected state of the build environment, without the need for explicit activation as in the above 2 methods. This only requires the use of the <activation> element in the profile definition. For example:
<profiles>
<profile>
<activation>
<
</profile>
</profiles>
The above code means: If JDK version start with 1.4 (eg. "1.4.0_08", "1.4.2_07", "1.4"), the profile will be activated
<profiles>
<profile>
<activation>
<property>
<name>debug</name>
</property>
</activation>
...
</profile>
</profiles>
The above code means: if there is a system property "debug", the profile will be debugged activation. To activate it, enter a command like:
mvn groupId:artifactId:goal –Ddebug
<profiles>
<profile>
<activation>
<property>
<name>environment</name>
<value>test</value>
</profiles>
The above code means: If there is a system property "environment" with a value of test, the profile will be activated. To activate it, enter a command like:
mvn groupId:artifactId:goal -Denvironment=test
4) Profiles can also automatically activate based on OS settings
<profiles>
<profile>
<activation>
<os>
<name>Windows XP</name>
<family>Windows</family>
<arch>x86</arch>
<version >5.1.2600</version>
</os>
</activation>
...
</profile>
</profiles>
The above code means: if the OS is windows xp, the profile will be activated
5) According to a certain file Activate the profile if it exists. For example, the profile defined below is activated when target/generated-sources/axistools/wsdl2java/org/apache/maven does not exist
<profiles>
<profile>
<activation>
<file>
<missing>
</activation>
...
</profile>
</profiles>
Two issues to pay attention to when using Profiles
First, external properties
are not defined in pom.xml The properties are called external properties. The best example is:
pom.xml:
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.myco.plugins</groupId>
<artifactId>spiffy-integrationTest-plugin</artifactId>
<version >1.0</version>
<configuration>
<appserverHome>${appserver.home}</appserverHome>
</configuration>
</plugin>
...
</plugins>
<
<settings>
...
<profiles>
<profile>
<id>appserverConfig</id>
<properties>
<appserver.home>/path/to/appserver</appserver.home>
</properties>
</profile>
</ profiles>
<activeProfiles>
<activeProfile>appserverConfig</activeProfile>
</activeProfiles>
...
</settings>
When you execute this pom, it works fine. But if another user executes, it fails because ${appserver.home} cannot be resolved (this is because the properties are defined in user-level settings.xml).
The solution is to define the profile in pom.xml, but the disadvantage of this is that each pom.xml that uses the profile must define the profile once.
The best solution is: Since Maven provides good support for project inheritance, it's possible to stick this sort of configuration in the pluginManagement section of a team-level POM or similar, and simply inherit the paths
Second, defined in pom.xml The profiles that do not meet the activation conditions are
still an example:
pom.xml:
<project>
...
<profiles>
<profile>
<id>appserverConfig-dev</id>
<activation>
<property>
<name>env</ name>
<value>dev</value>
</property>
</activation>
<properties>
<appserver.home>/path/to/dev/appserver</appserver.home>
</properties>
</profile>
<profile>
<id>appserverConfig-dev-2</id>
<activation>
<property>
<name>env</name>
<value>dev-2</value>
</property>
</activation>
<properties>
<appserver.home>/path/to/dev/appserver2</appserver.home>
</properties>
</profile>
</profiles>
<build>
<plugins>
<plugin>
<groupId>org.myco.plugins</groupId>
<artifactId>spiffy-integrationTest-plugin</artifactId>
<version>1.0</version>
<configuration>
<appserverHome>${appserver.home}</appserverHome>
</configuration>
</plugin>
...
</plugins>
</build>
...
</project>
The pom.xml defined above defines two profiles: different "env" parameter values will activate different profiles. When executing the command:
mvn -Denv=dev-2 integration-test
will activate the profile "appserverConfig-dev-2"
When executing the command:
mvn -Denv=dev integration-test
will activate the profile "appserverConfig-dev"
and when executing the command :
mvn -Denv=production integration-test
fails because no profile is activated, so ${appserver.home} cannot be resolved.
To see which Profiles are used during build time,
execute the active-profiles goal of the help plugin, use the command:
mvn help:active-profiles
Example:
For the above example, if you enter the command:
mvn help:active-profiles -Denv=dev
, the output will be The ones are:
The following profiles are active:
- appserverConfig-dev (source: pom)
If there is a profile defined in settings.xml and activated with <activeProfile>, then enter the command:
mvn help:active-profiles
and the output is:
The following profiles are active:
- appserverConfig ( source: settings.xml)
If you enter the command:
mvn help:active-profiles -P appserverConfig-dev
then the output is:
The following profiles are active:
- appserverConfig-dev (source: pom)
- appserverConfig (source: settings.xml)