maven’s setting.xml configuration to solve the problem of excessive maven download speed

Add it to the mirror tag in the setting.xml file

**** **alimaven** **central** **aliyun maven** **http://maven.aliyun.com/nexus/content/repositories/central/** ****

The maven configuration file settings.xml exists in two places:

1. Installation place: ${M2_HOME}/conf/settings.xml

2. User’s directory: ${user.home}/.m2/settings.xml

The former is also called global configuration and is effective for all users of the operating system; the latter is called user configuration and is only effective for users of the current operating system. If both are present, their contents are merged and the user-scope settings.xml overrides the global settings.xml.

After Maven is installed, settings.xml will not be automatically generated in the user directory, only the global configuration file. If you need to create user-scope settings.xml, you can copy the settings in the installation path to the directory ${user.home}/.m2/. Maven’s default settings.xml is a template containing comments and examples, which can be quickly modified to meet your requirements.

Once the global configuration is changed, all users will be affected, and if Maven is upgraded, all configurations will be cleared, so you must copy and back up the ${M2_HOME}/conf/settings.xml file in advance. Generally, it is not recommended to configure the global configuration. settings.xml.

?xml version=”1.0″ encoding=”UTF-8″?>

 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"\>

 <!--Local warehouse. This value represents the path to the local repository of the build system. Its default value is ${user.home}/.m2/repository. -->

 <localRepository\>usr/local/maven</localRepository\>

 <!--Whether Maven needs to interact with the user to obtain input. Set to true if Maven needs to interact with the user to obtain input, otherwise it should be false. Default is true. -->

 <interactiveMode\>true</interactiveMode\>

 <!--Whether Maven needs to use the plugin-registry.xml file to manage plug-in versions. -->

 <!--If set to true, there needs to be a plugin-registry.xml under {user.home}/.m2 to manage the plugin version -->

```
 
```

 <usePluginRegistry\>false</usePluginRegistry\>

 <!--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 very useful when the build server cannot connect to the remote warehouse due to network settings or security reasons. -->

```
 <offline\>false</offline\>
```

 <!--When the plug-in's organization ID (groupId) is not provided explicitly, a list for searching the plug-in organization ID (groupId). -->

 <!--This element contains a list of pluginGroup elements, and each sub-element contains an organization ID (groupId). -->

 <!--Maven will use this list when we use a plug-in and do not provide it with an organization ID (groupId) on the command line. -->

 <!--This list includes org.apache.maven.plugins by default. -->

```
 <pluginGroups\>
```

 <!--plugin's organization ID (groupId) -->

 <pluginGroup\>org.codehaus.mojo</pluginGroup\>

```
 </pluginGroups\>
```

 <!--Used to configure different agents, multi-agent profiles can cope with the working environment of laptops or mobile devices: the entire agent configuration can be easily changed by simply setting the profile id. -->

```
 <proxies\>
```

 <!--The proxy element contains the 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\>
```

 <!--Agent's protocol. 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 proxy username, username and password 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\>
```

 <!--Configure some settings on the server. 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\>my\_password</password\>
```

 <!--The location of the private key used for authentication. Similar to the first two elements, the private key location and private key password specify the path to a private key (default is /home/hudson/.ssh/id\_dsa) and, if needed, a secret key -->

 <!--The passphrase and password elements may be extracted externally in the future, 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\>

 <!--Additional configuration items for the transport layer -->

```
 <configuration\></configuration\>
```
```
 </server\>
```
```
 </servers\>
```

 <!--Download mirror list configured for the warehouse list. -->

```
 <mirrors\>
```

 <!--The download image of the given warehouse. -->

```
 <mirror\>
```

 <!--The unique identifier of the image. The id is used to distinguish different mirror elements. -->

```
 <id\>planetmirror.com</id\>
```
```
 
```
```
 <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 mirrored server. For example, if we want to set up a mirror of the Maven central repository (http://repo1.maven.org/maven2), -->

 <!--You need to set the element to central. This must be exactly the same as the id central of the central warehouse. -->

```
 <mirrorOf\>central</mirrorOf\>
```
```
 </mirror\>
```
```
 </mirrors\>
```

 <!--A list of build configurations that can be adjusted 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 is activated, its value will overwrite any other profile with the same id defined in the POM or profile.xml. -->

```
 <profiles\>
```

 <!--Configuration of components adjusted according to environmental parameters -->

```
 <profile\>
```

 <!--The unique identifier of this configuration. -->

```
 <id\>test</id\>
```

 <!--The conditional logic that automatically triggers the profile. Activation is the key to opening the profile. -->

 <!--Like the profile in the POM, the power of the profile comes from its ability to 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. -->

 <!--Profile 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\>

 <!--activation has a built-in java version detection. If the jdk version is detected to be the same as expected, the profile is activated. -->

```
 <jdk\>1.7</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 that activates the profile (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 through ${name} in the POM), which has the corresponding name and 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\>/usr/local/hudson/hudson-home/jobs/maven-guide-en-to-production/workspace/</exists\>

 <!--If the specified file does not exist, activate the profile. -->

 <missing\>/usr/local/hudson/hudson-home/jobs/maven-guide-en-to-production/workspace/</missing\>

```
 </file\>
```
```
 </activation\>
```

 <!--Extended attribute list corresponding to profile. Maven properties are the same as properties in Ant and can be used to store some values. These values can be used anywhere in the POM using the tag ${X}, where X refers to the name of the attribute. -->

 <!--Attributes come in five different forms and can all be accessed 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. -->

 <!--3. settings.x: refers to the value of the corresponding element in settings.xml. -->

 <!--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 /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre. -->

 <!--5. x: Set in the <properties/> element or in an external file, in the form of ${someVar}. -->

```
 <properties\>
```

 <!-- If this profile is activated, the attribute ${user.install} can be accessed -->

 <user.install\>usr/local/winner/jobs/maven-guide</user.install\>

```
 </properties\>
```

 <!--Remote warehouse list, which is a set of remote projects 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\>
```
```
 
```
```
 <name\>Codehaus Snapshots</name\>
```

 <!--How to handle the download of the release version in the remote warehouse -->

```
 <releases\>
```

 <!--true or false indicates whether the warehouse is enabled 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 (failure), or warn (warning). -->

 <checksumPolicy\>warn</checksumPolicy\>

```
 </releases\>
```

 <!--How to handle downloading snapshot versions from remote repositories. 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 enable 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\>
```

 <!--Discover the remote repository list of plug-ins. A warehouse is home to two main components. The first type of component is used as a dependency on other components. This is the type of most artifacts stored in the central warehouse. Another component type is a plug-in. -->

 <!--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\>
```

 <!--A list of manually activated profiles, defining 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, regardless of the environment settings, its corresponding profile will be activated. -->

 <!--If there is no matching profile, nothing will happen. 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 running process, Maven will run as usual. -->

```
 <activeProfiles\>
```

 <activeProfile\>env-test</activeProfile\>

```
 </activeProfiles\>
```
```
 </profile\>
```
```
 </profiles\>
```

The above configuration file has annotations on the meaning and function of each node. In actual applications, a limited number of nodes are often used, and the default values of other nodes are sufficient to cope with most application scenarios.

Node

In the warehouse configuration section, the common nodes in setting.xml have been explained in detail. What needs special introduction here is the configuration of nodes. Profile is an important feature of maven.

The node includes activation, repositories, **plugin repositories (pluginRepositories)andproperties** in total. child element element. The profile element only contains these four elements because they relate to the entire build system, not individual project-level POM configurations.

Profile allows Maven to automatically adapt to changes in the external environment. For example, for the same project, compile the linux version under Linux, compile the win version under win, etc. A project can set multiple profiles, and multiple profiles can be set to be active at the same time. The conditions for automatically activated profiles can be a variety of setting conditions, which are combined in the activation node, or can be specified directly through the command line. If you think the profile settings are more complicated, you can move all the profiles content to a special profiles.xml file, but remember to put it together with pom.xml.

The activation node sets the conditions under which the profile will be activated. Common conditions include the following:

Determine the parameters related to the operating system, which contains the following sub-node elements that can be freely combined

message – the message to display after the rule fails

arch – matches the cpu structure, usually x86

family – matches the operating system family. Common values are: dos, mac, netware, os/2, unix, windows, win9x, os/400, etc.

name – the name matching the operating system

version – the matching operating system version number

display – the information displayed after the operating system is detected

jdk

Check the jdk version, which can be expressed as an interval.

property

Check the attribute value. This node can contain two child nodes: name and value.

file

Check the file-related content, including two sub-nodes: exists and missing, which are used to check the existence and non-existence of the file respectively.

If the profile in settings is activated, its value will overwrite any profiles with equal ID in POM or profiles.xml.

If you want a profile to be activated by default, you can put the id of the profile in. In this way, regardless of the environment settings, the corresponding profile will be activated.

Insert image description here