Maven Advanced: About the properties of the POM.XML configuration file, multi-environment configuration,

Properties tag  <properties>

1. Centrally manage the dependent versions imported under the project

For example:

We can clearly know which dependency package corresponds to which version.

So is it also supported for the configuration information of the database?

The answer is yes.

Manage database configuration information in a unified manner by customizing labels.

For example:

Go back to the configuration file and replace it with a placeholder

But to make the system recognize the placeholder, you need to expand the scope of the pom file

The <filtering>  tag is used to configure the recognition filter, which is used to identify placeholders in the configuration file.

Then we enter the test

 After the packaging is complete, enter the directory

 

 Open the jar package and open the configuration file

We can see that the configuration information has been successfully configured.

 Let's talk about how to configure maven projects in complex and diverse development environments

 Different development environments require different configuration information

The development environment can be divided into three types: development (dev), testing (test), production (pro)

<profiles> --> <properties> : We write the configuration information under the properties tag

 The following are configuration examples for the three development environments:

 Then set whether it is the default startup environment

Set the tag to   <activation> --> <activeByDefault> 

 In order to be more effective, we change its port number to the following

After executing the package life cycle of maven, reopen the configuration file. We can see that the default startup environment configuration has been configured

 The second method is also the most used method in the development industry: directly execute the command line

Enter the command: mvn install -P environment ID

You can specify the development environment for execution, which is simple and efficient. Of course, it still has to be configured, otherwise there is no environment id

 In development, testing is useful for us. But sometimes there are too many test cases, a lot of information will be deleted, and the execution efficiency is very low. What if we don't want to test

 

The following is a very simple method, you can skip the test by directly clicking the maven settings under IDEA.

For example:

 But this is to skip the test life cycle of all project modules, but sometimes we prefer to only skip the tests we don't want. Then consider using the following approach

Let's configure maven's management test plugin by ourselves

Run the package life cycle first to find the artifact id of the plugin 

Then configure the plugin

<plugins> --> <configuration> --> <skipTests> : Set whether to skip tests

Why is there no <groupId> tag? It is because this test plug-in comes with maven internally

 This starts the life cycle and we won't see the test appear

 You can also manage the test more finely. I believe the following two labels are familiar to you.

<include> includes         <exclude> excludes

 In the following example, the code means: Exclude testing of this test class under any package of the project

 We can't see this class being tested in the running results

knock off!

Guess you like

Origin blog.csdn.net/Ccc67ol/article/details/127355388