This is the 28th day of my participation in the November Gwen Challenge. Check out the event details: The last Gwen Challenge 2021

Maven will parse the Settings file

When you start a new company, a lot of times you need to ask an old employee for a Settings file. This article describes these configuration items of Settings and what they do. If you sort out the company environment when what problems, you can look up and analyze the investigation.

Maven configuration files have two levels:

  1. User level Maven configuration settings.xml
    • It is usually placed in the ${user.home}/.m2/settings. XML directory
    • – s/path/to/user/Settings. The XML override the default Settings file
  2. Maven configures settings.xml at the global level
    • It is usually placed in the ${maven.conf}/settings. XML directory
    • – gs/path/to/global/Settings. The XML can specify override the default configuration Settings file

localRepository

 <localRepository>/xxx/env/maven/repo</localRepository>
Copy the code

Configuration of the local repository path

  • The default:${user.home}/.m2/repository
  • Specify:<localRepository>/path/to/local/repo</localRepository>

interactiveMode

<interactiveMode>true</interactiveMode>
Copy the code

InteractiveMode Interaction mode, indicating whether to interact with user input. If set to false, Maven will try to use the default value instead. (i.e., whether to interact with users when executing maven commands)

For example, when creating a project on the command line, we need to specify the GAV of the project, which maven cannot replace with default values, so it will fail directly.

Default: true,

offline

<offline>false</offline>
Copy the code

If offline Maven needs to run in offline mode, set it to true if you do not want to connect to a remote repository, then you will not pull jars from the remote repository. This configuration is generally not used.

Default: false

pluginGroups

  <pluginGroups>
    <! PluginGroup <pluginGroup>com.your.plugins</pluginGroup> -->
  </pluginGroups>
Copy the code

The groupIds candidate for pluginGroups

  • If the groupId of the specified plugin is not displayed, Maven will look for the plugin in the configured groupId
  • By default, maven adds “org.apache.maven.plugins” and “org.codehaus. Mojo “groupId

proxies

  <proxies>
    <! -- proxy <proxy> <id>optional</id> this id is the same as the profile ID, Can be globally specified to switch <active>true</active> <protocol> HTTP </protocol> <username>proxyuser</username> <password>proxypass</password> <host>proxy.host.net</host> <port>80</port> <nonProxyHosts>local.net|some.host.com</nonProxyHosts> </proxy> -->
  </proxies>
Copy the code

Proxies may need to be configured to access remote warehouses through security concerns such as firewalls. The first proxy configuration in the list is used by default unless specified (system configuration properties or command line specified switching).

servers

  <servers>
    <server>
      <id>deploymentRepo</id> 
      <username>repouser</username>
      <password>repopwd</password>
    </server>
  </servers>
Copy the code

It is mainly used to connect the private server when some authentication needs information. (The attribute of id must be globally unique), you can configure two types:

1. Account password (most passwords are configured) 2. PrivateKeyCopy the code

When we upload jar packages, we usually need some authentication information. At this time, we need to specify the server authentication information of the corresponding warehouse. For security, warehouse information can be configured directly in the POM file, and authentication information must be configured in settings.xml.

This ID must match the ID of the Repository element in distributionManagement! This id is needed to obtain authentication information before the JAR can be uploaded. Ideally, this id corresponds to the repository/mirror iD, which represents the same set.

mirrors

  <mirrors>
    <mirror>
      <id>alimaven</id>
      <! -- Specify the address of a mirror, not the address of the repository. ID must be unique -->
      <name>aliyun maven</name>
      <url>http://maven.aliyun.com/nexus/content/groups/public/</url>
      <mirrorOf>*</mirrorOf>
  </mirrors>
Copy the code

Configure a mirror. A mirror usually corresponds to a remote repository. Specify the ID of the repository through the mirrorOf configuration. For example, central is specified above, indicating that this image is the mirror of Maven’s central repository.

Maven will use the repository ID to check whether mirrorOf is configured. If there is a mirrorOf id, Maven will intercept the request and forward the request to the mirror library. Otherwise, use the Repository configuration.

If a POM specified JAR package is pulled to a repository in real time every time, the network transmission pressure is very high, so people set up mirror libraries in multiple places to disperse the pressure.

In general, because of the ID of the server being mirrored, we can set up a mirror service, where mirrorOf is to specify which remote warehouse the mirror belongs to. For example: The default ID of our Maven central repository is central, and we set up a mirror of the repository, specifying central. Each server configuration has a unique ID attribute, and this image is preferred when additional JARS are pulled from a Repository with the same ID.

For example, we usually set the address of Ali Cloud mirror library to the address of Maven’s central repository to speed up access.

The key configuration

One of the more important properties in mirror is mirrorOf:

MirrorOf: This configuration can take many forms:

  1. If we specify the repository ID, then the image will be used to pull the jar of this repository. (Multiple REPO configurations are supported)
  2. We can also configure it*That means all remote services will be mirrored to the agent! Then all pull JAR requests for the remote service will be forwarded to the image!This may cause us to configure a private server and not be able to use it.
  3. configurationexternal:*: represents all remote repositories that match the locally deployed repository (starting with localhost or file:// repository configuration starting with protocol).
  4. configuration*,!repo1Matches all remote repositories except rePO1. That is, REPO1 still uses its own REPO address, while the others use the mirror.

conclusion

Configuring a Single Mirror

  • Repository has no counterpart<mirrorOf>Specifies that will be pulled from the repository configuration address
  • <mirrorOf>If the repository id is specified, the mirror address is preferred.
  • <mirrorOf>Specifies the*That is, all repositories will use the address of mirror.

Multiple Mirror Configurations

  • multi-configured<mirrorOf>If you specify the same ID, only the first mirror will be used

profiles

  <profiles>
    <! -- This is the JDK prefix to match the configuration -->
    <profile>
      <id>JDK - 1.4 -</id>
      <activation>
        <jdk>1.4</jdk>
      </activation>
      <repositories>
        <repository>
          <id>jdk14</id>
          <name>Repository for JDK 1.4 builds</name>
          <url>http://www.myhost.com/maven/jdk14</url>
          <layout>default</layout>
          <snapshotPolicy>always</snapshotPolicy>
        </repository>
      </repositories>
    </profile>
    <! -- Configuration specified by environment -->
    <profile>
      <id>env-dev</id>
      <activation>
        <property>
          <name>target-env</name>
          <value>dev</value>
        </property>
      </activation>
      <! You can set some properties here -->
      <properties>
        <tomcatPath>/path/to/tomcat/instance</tomcatPath>
      </properties>
    </profile>
	<! -- General configuration -->
    <profile>
      <id>central</id>
      <repositories>
        <repository>
          <id>central</id>
          <name>local private nexus</name>
          <url>http://xxxx/repositories/public</url>
          <releases>
            <enabled>true</enabled>
          </releases>
          <snapshots>
            <enabled>true</enabled>
          </snapshots>
        </repository>
      </repositories>
      <pluginRepositories>
        <pluginRepository>
          <id>central</id>
          <name>local private nexus</name>
          <url>http://xxxx/public</url>
          <releases>
            <enabled>true</enabled>
          </releases>
          <snapshots>
            <enabled>true</enabled>
          </snapshots>
        </pluginRepository>
      </pluginRepositories>
    </profile>
  </profiles>
Copy the code

Configure the configuration information of different environments, mainly stores the corresponding configurations in different environments. We typically use this to isolate test/production environments and use different configurations for different environments, especially for configuring the Repository environment private server information.

The configuration can be activated in a number of ways:

  1. The following activeProfiles TAB configures the specified environment
  2. System configuration properties specified
  3. If the JDK version prefix matches, for example, JDK version 1.4.2_07, 1.4 can be activated
  4. This can be specified by command line arguments

activeProfiles

  <activeProfiles>
    <activeProfile>alwaysActiveProfile</activeProfile>
    <activeProfile>anotherAlwaysActiveProfile</activeProfile>
  </activeProfiles>
Copy the code

This parameter specifies the profile that needs to be activated by default. If the profile has a corresponding configuration, the profile is activated. If the profile does not have a corresponding configuration, the profile is ignored. If multiple profiles are specified, these profiles will be used in turn to find jar packages that cannot be found.

This profile can be configured in our POM file similar to the global and current project relationship.