1. Interpretation of setting
1.maven warehouse configuration
The warehouse priority is: local warehouse (localRepositories) > repositories warehouse in profile > POM > mirrors global warehouse
What is the use of settings.xml?
If you have used the Maven plug-in in Eclipse, you must have this experience: configure the path of the settings.xml file.
What does the settings.xml file do and why do we need to configure it?
As you can see from the file name of settings.xml, it is a configuration file used to set maven parameters. Moreover, settings.xml is the global configuration file of maven. The pom.xml file is the local configuration of the project.
Settings.xml contains configurations such as local storage location, modification of remote storage server, authentication information, etc.
settings.xml file location
The settings.xml file generally exists in two locations:
Global configuration: ${M2_HOME}/conf/settings.xml
User configuration: {user.home} and all other system properties are only available on version 3.0+. Please note the difference in the use of variables in Windows and Linux.
Configure priority
It should be noted that local configuration takes precedence over global configuration.
Configuration priority from high to low: pom.xml> user settings> global settings
If these files exist at the same time, their contents will be merged when applying the configuration. If there are duplicate configurations, the configuration with higher priority will overwrite the one with lower priority.
Detailed explanation of settings.xml elements
Overview of top-level elements
The following lists the top-level elements in settings.xml
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
https://maven.apache.org/xsd/settings-1.0.0.xsd">
<localRepository/>
<interactiveMode/>
<usePluginRegistry/>
<offline/>
<pluginGroups/>
<servers/>
<mirrors/>
<proxies/>
<profiles/>
<activeProfiles/>
</settings>
LocalRepository
Function: This value represents the path to the local warehouse of the build system.
Its default value: ~/.m2/repository.
<localRepository>${user.home}/.m2/repository</localRepository>
InteractiveMode
Function: Indicates whether maven needs to interact with the user to obtain input.
If maven needs to interact with the user to obtain input, set it to true, otherwise it should be false. Default is true.
<interactiveMode>true</interactiveMode>
UsePluginRegistry
Function: Whether maven needs to use the plugin-registry.xml file to manage plug-in versions.
Set to true if you need to let maven use the file ~/.m2/plugin-registry.xml to manage plug-in versions. Default is false.
<usePluginRegistry>false</usePluginRegistry>
Offline
Function: Indicates whether maven needs to run in offline mode.
True if the build system needs to run in offline mode, defaults to false.
This configuration is useful when the build server cannot connect to the remote repository due to network setup or security reasons.
<offline>false</offline>
PluginGroups
Function: When the plug-in's organization ID (groupId) is not provided explicitly, the list of plug-in organization IDs (groupId) is used to search.
This element contains a list of pluginGroup elements, each sub-element containing an organization ID (groupId).
Maven will use this list when we use a plug-in and do not provide an organization ID (groupId) on the command line. By default this list includes org.apache.maven.plugins and org.codehaus.mojo.
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
https://maven.apache.org/xsd/settings-1.0.0.xsd">
...
<pluginGroups>
<!--plugin’s organization ID (groupId) -->
<pluginGroup>org.codehaus.mojo</pluginGroup>
</pluginGroups>
...
</settings>
Servers
Function: Generally, the download and deployment of the warehouse are defined in the repositories and distributionManagement elements in the pom.xml file. However, generally information such as username and password (some warehouse access requires security authentication) should not be configured in the pom.xml file. This information can be configured in settings.xml.
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
https://maven.apache.org/xsd/settings-1.0.0.xsd">
...
<!--Configure some settings on the server side. Some settings such as security certificates should not be distributed with pom.xml. This type of information should be present in the settings.xml file on the build server. -->
<servers>
<!--The server element contains information needed to configure the server -->
<server>
<!--This is the id of the server (note that it is not the id of the user's login). This id matches the id of the repository element in distributionManagement. -->
<id>server001</id>
<!--Authentication username. The authentication user name and authentication password represent the login name and password required for server authentication. -->
<username>my_login</username>
<!--Authentication password. The authentication user name and authentication password represent the login name and password required for server authentication. Password encryption functionality has been added to 2.1.0+. For details, please visit the password encryption page -->
<password>my_password</password>
<!--The location of the private key used for authentication. Similar to the previous two elements, the private key location and private key password specify a path to the private key (default is ${user.home}/.ssh/id_dsa) and, if required, a passphrase. In the future the passphrase and password elements may be extracted externally, but currently they must be declared in plain text in the settings.xml file. -->
<privateKey>${usr.home}/.ssh/id_dsa</privateKey>
<!--Private key password used for authentication. -->
<passphrase>some_passphrase</passphrase>
<!--The permissions when the file was created. If a warehouse file or directory will be created during deployment, permissions can be used at this time. The legal value of these two elements is a three-digit number, which corresponds to the permissions of the Unix file system, such as 664, or 775. -->
<filePermissions>664</filePermissions>
<!--Permissions when the directory is created. -->
<directoryPermissions>775</directoryPermissions>
</server>
</servers>
...
</settings>
Mirrors
Function: Download mirror list configured for the warehouse list.
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
https://maven.apache.org/xsd/settings-1.0.0.xsd">
...
<mirrors>
<!-- The download image for the given repository. -->
<mirror>
<!-- The unique identifier of this image. The id is used to distinguish different mirror elements. -->
<id>planetmirror.com</id>
<!-- Image name -->
<name>PlanetMirror Australia</name>
<!-- The URL of the image. The build system will use this URL in preference to the default server URL. -->
<url>http://downloads.planetmirror.com/pub/maven2</url>
<!-- The id of the server being mirrored. For example, if we want to set up a mirror of the Maven central repository (http://repo.maven.apache.org/maven2/), we need to set this element to central. This must be exactly the same as the id central of the central warehouse. -->
<mirrorOf>central</mirrorOf>
</mirror>
</mirrors>
...
</settings>
Proxies
Function: Used to configure different agents.
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
https://maven.apache.org/xsd/settings-1.0.0.xsd">
...
<proxies>
<!--The proxy element contains information needed to configure the proxy -->
<proxy>
<!--The unique definer of the agent, used to distinguish different agent elements. -->
<id>myproxy</id>
<!--Whether the agent is the active one. true activates the agent. This element can be useful when we declare a group of agents and only need to activate one agent at a time. -->
<active>true</active>
<!--The agent's agreement. protocol://hostname:port, separated into discrete elements for ease of configuration. -->
<protocol>http</protocol>
<!--The host name of the agent. protocol://hostname:port, separated into discrete elements for ease of configuration. -->
<host>proxy.somewhere.com</host>
<!--The port of the proxy. protocol://hostname:port, separated into discrete elements for ease of configuration. -->
<port>8080</port>
<!--The username, username and password of the proxy represent the login name and password for proxy server authentication. -->
<username>proxyuser</username>
<!--The proxy's password, username and password represent the login name and password for proxy server authentication. -->
<password>somepassword</password>
<!--List of hostnames that should not be proxied. The delimiter for this list is specified by the proxy server; pipe delimiters are used in the example, but commas are also common. -->
<nonProxyHosts>*.google.com|ibiblio.org</nonProxyHosts>
</proxy>
</proxies>
...
</settings>
Profiles
Function: Adjust the list of build configurations based on environment parameters.
The profile element in settings.xml is a tailored version of the profile element in pom.xml.
It contains id, activation, repositories, pluginRepositories and properties elements. The profile element here only contains these five sub-elements because it only cares about the build system as a whole (this is the role of the settings.xml file), not individual project object model settings. If a profile in settings.xml is activated, its value will override any other profile defined in pom.xml with the same id.
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
https://maven.apache.org/xsd/settings-1.0.0.xsd">
...
<profiles>
<profile>
<!-- The unique identifier of the profile -->
<id>test</id>
<!-- Automatically trigger the conditional logic of profile -->
<activation />
<!-- Extended attribute list -->
<properties />
<!-- Remote warehouse list -->
<repositories />
<!-- Plug-in repository list -->
<pluginRepositories />
</profile>
</profiles>
...
</settings>
Activation
Function: Automatically trigger the conditional logic of the profile.
Like the profile in pom.xml, the role of the profile is that it can automatically use certain values in certain specific environments; these environments are specified through the activation element.
The activation element is not the only way to activate a profile. The activeProfile element in the settings.xml file can contain the profile id. Profiles can also be activated explicitly on the command line using the -P flag and a comma-separated list (e.g., -P test).
<activation>
<!--Indicates whether the profile is activated by default -->
<activeByDefault>false</activeByDefault>
<!--When the matching jdk is detected, the profile is activated. For example, 1.4 activates JDK1.4, 1.4.0_2, while !1.4 activates all JDK versions that do not start with 1.4. -->
<jdk>1.5</jdk>
<!--When matching operating system attributes are detected, the profile is activated. The os element can define some operating system-related attributes. -->
<os>
<!--The name of the operating system that activates the profile -->
<name>Windows XP</name>
<!--The family of the operating system to which the profile is activated (such as 'windows') -->
<family>Windows</family>
<!--The operating system architecture of the activated profile -->
<arch>x86</arch>
<!--The operating system version of the activated profile -->
<version>5.1.2600</version>
</os>
<!--If Maven detects a property (its value can be referenced by ${name} in the POM), which has a corresponding name = value, the Profile will be activated. If the value field is empty, then the profile will be activated if the attribute name field exists, otherwise the attribute value field will be matched in a case-sensitive manner -->
<property>
<!--The name of the attribute that activates the profile -->
<name>mavenVersion</name>
<!--The value of the attribute that activates the profile -->
<value>2.0.3</value>
</property>
<!--Provide a file name to activate the profile by detecting the presence or absence of the file. missing checks whether the file exists and activates the profile if it does not exist. On the other hand, exists checks whether the file exists and activates the profile if it exists. -->
<file>
<!--If the specified file exists, activate the profile. -->
<exists>${basedir}/file2.properties</exists>
<!--If the specified file does not exist, activate the profile. -->
<missing>${basedir}/file1.properties</missing>
</file>
</activation>
Note: Execute the mvn help:active-profiles command in the directory where the pom.xml of the maven project is located to check whether the profile of the central repository is effective in the project.
properties
Function: A list of extended attributes corresponding to the profile.
Maven attributes are the same as attributes in ant and can be used to store some values. These values can be used anywhere in pom.xml using the tag ${X}, where X refers to the name of the attribute. Properties come in five different forms and are all accessible in the settings.xml file.
<!--
1. env.X: Prefixing a variable with "env." will return a shell environment variable. For example, "env.PATH" refers to the $path environment variable (%PATH% on Windows).
2. project.x: refers to the corresponding element value in the POM. For example: <project><version>1.0</version></project> gets the version value through ${project.version}.
3. settings.x: refers to the value of the corresponding element in settings.xml. For example: <settings><offline>false</offline></settings>Get the value of offline through ${settings.offline}.
4. Java System Properties: All properties that can be accessed through java.lang.System.getProperties() can be accessed using this form in the POM, such as ${java.home}.
5. x: Set in the <properties/> element or in an external file, and use it in the form of ${someVar}.
-->
<properties>
<user.install>${user.home}/our-project</user.install>
</properties>
Note: If the profile is activated, you can use ${user.install} in pom.xml.
Repositories
Function: Remote warehouse list, which is a set of remote warehouses used by maven to populate the local warehouse of the build system.
<repositories>
<!--Contains information needed to connect to the remote warehouse -->
<repository>
<!--The unique identifier of the remote warehouse -->
<id>codehausSnapshots</id>
<!--Remote warehouse name -->
<name>Codehaus Snapshots</name>
<!--How to handle downloading the release version from the remote warehouse -->
<releases>
<!--true or false indicates whether the warehouse is opened for downloading certain types of components (release version, snapshot version). -->
<enabled>false</enabled>
<!--This element specifies how often updates occur. Maven will compare the timestamps of the local POM and the remote POM. The options here are: always (always), daily (default, daily), interval: X (where X is the time interval in minutes), or never (never). -->
<updatePolicy>always</updatePolicy>
<!--What to do when Maven fails to verify the component verification file - ignore (ignore), fail (fail), or warn (warn). -->
<checksumPolicy>warn</checksumPolicy>
</releases>
<!--How to handle the download of snapshot versions in remote warehouses. With the two sets of configurations, releases and snapshots, POM can adopt different strategies for each type of component in each separate warehouse. For example, someone might decide to turn on support for snapshot version downloads only for development purposes. See repositories/repository/releases element -->
<snapshots>
<enabled />
<updatePolicy />
<checksumPolicy />
</snapshots>
<!--Remote warehouse URL, in the form of protocol://hostname/path -->
<url>http://snapshots.maven.codehaus.org/maven2</url>
<!--The warehouse layout type used to position and sort components-can be default (default) or legacy (legacy). Maven 2 provides a default layout for its repository; however, Maven 1.x has a different layout. We can use this element to specify whether the layout is default or legacy. -->
<layout>default</layout>
</repository>
</repositories>
pluginRepositories
Function: Discover the remote repository list of plug-ins.
Similar to repository, except that repository is a warehouse that manages jar package dependencies, and pluginRepositories is a warehouse that manages plug-ins.
Maven plug-in is a special type of component. For this reason, plugin repositories are independent of other repositories. The structure of the pluginRepositories element is similar to that of the repositories element. Each pluginRepository element specifies a remote address that Maven can use to find new plugins.
<pluginRepositories>
<!-- Contains information needed to connect to the remote plug-in repository. See the description of the profiles/profile/repositories/repository element -->
<pluginRepository>
<releases>
<enabled />
<updatePolicy />
<checksumPolicy />
</releases>
<snapshots>
<enabled />
<updatePolicy />
<checksumPolicy />
</snapshots>
<id />
<name />
<url />
<layout />
</pluginRepository>
</pluginRepositories>
ActiveProfiles
Function: Manually activate the list of profiles, and define activeProfile in the order in which the profiles are applied.
This element contains a set of activeProfile elements, each activeProfile contains a profile id. Any profile id defined in activeProfile will have its corresponding profile activated regardless of the environment settings. If there is no matching profile, nothing happens.
For example, if env-test is an activeProfile, the profile corresponding to the id in pom.xml (or profile.xml) will be activated. If such a profile is not found during the run, Maven will run as usual.
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
https://maven.apache.org/xsd/settings-1.0.0.xsd">
...
<activeProfiles>
<!-- Profile id to be activated -->
<activeProfile>env-test</activeProfile>
</activeProfiles>
...
</settings>
2. Commonly used maven commands
maven commonly used packaging commands
1. mvn compile compiles Java source programs into class bytecode files.
2. mvn test test and generate test report
3. mvn clean deletes the old class bytecode files compiled previously
4. mvn pakage packaging, dynamic web projects are packaged in war packages, and Java projects are packaged in jar packages.
5. mvn install puts the project-generated jar package in the warehouse so that other modules can call it.
6. mvn clean install -Dmaven.test.skip=true into a jar package and discard the test case packaging
7. mvn clean pakage -Dmaven.test.skip=true dynamic web project into war package, Java project into jar package, and abandon test case packaging
Maven can use the mvn package command to package the project. If you use java -jar xxx.jar to run the jar file, “no main manifest attribute, in xxx.jar” (Main-Class is not set) or ClassNotFoundException (cannot be found) will appear. dependency package) and other errors.
If you want the jar package to run directly through java -jar xxx.jar, you need to meet the following requirements:
1. Specify Main-Class in META-INF/MANIFEST.MF in the jar package, so as to determine where the entry point of the program is;
2. Dependency packages must be loaded.
Configure in pom.xml:
org.springframework.boot spring-boot-maven-plugin com.zyd.blog.BlogWebApplication JAR
true
3. Remote warehouse addresses commonly used by maven
- Alibaba Cloud remote warehouse
<mirror>
<id>nexus-aliyun</id>
<name>Nexus aliyun</name>
<url>http://maven.aliyun.com/nexus/content/groups/public/</url>
<mirrorOf>central</mirrorOf>
</mirror>
- Maven official operation and maintenance No. 2 warehouse
<mirror>
<id>repo2</id>
<name>Mirror from Maven Repo2</name>
<url>http://repo2.maven.org/maven2/</url>
<mirrorOf>central</mirrorOf>
</mirror>
- Warehouse set up by maven in UK
<mirror>
<id>ui</id>
<name>Mirror from UK</name>
<url>http://uk.maven.org/maven2/</url>
<mirrorOf>central</mirrorOf>
</mirror>
- JBoss repository
<mirror>
<id>jboss-public-repository-group</id>
<mirrorOf>central</mirrorOf>
<name>JBoss Public Repository Group</name>
<url>http://repository.jboss.org/nexus/content/groups/public</url>
</mirror>
3. compile, test, provided in tags
Introducing the junit package, then this jar package will only work in the test project phase of the maven cycle;
compile will play a role in compilation, testing, packaging, deployment, etc.;
provided: Indicates that this jar package is provided by the server, and the project itself does not need to be brought; it only works during compilation and testing
4. Solutions to maven error reports
1. When using maven to package packages, the following errors sometimes occur:
There are test failures.
Please refer to XXX/target/surefire-reports for the individual test results
This indicates that packaging failed due to test failure. The solution is to skip test packaging.
1. Command line form (universal)
Command 1: mvn package -Dmaven.test.skip=true
or
Command 2: mvn package -DskipTests
or
Command 3: mvn package -Dmaven.test.failure.ignore=true
All of the above are possible, but there are certain differences
Command 1: Test cases will not be executed and test cases will not be compiled.
Command 2: The test case will not be executed, but the test case will be compiled (if the compilation also reports an error, then use command 1)
Command 3: Ignore test errors and continue building even if it fails
2. System solutions
