MAVEN local warehouse and remote repository

In Maven, any dependency, plug-in, or project-built output can be called artifacts.

Maven stores the shared artifacts of all projects in a single, unified location that we call warehouses. (Warehouses are places where dependencies and plugins are stored)

Any component has a unique coordinate, and MAVEN defines the unique storage path for the component in the warehouse, based on this coordinate.

Read MAVEN's storage path in the repository:

1. Based on the GroupID preparation path, turn the period separator into a path delimiter, that is, "." Converted to "/"; example:org.testng--->org/testng

2. Based on the Artifactid preparation path, connect the Artifactid to the back: org/testng/testng

3. Use version to prepare the path and connect version to the following: org/testng/testng/5.8

4. connect Artifactid to version with a delimiter hyphen to the back: org/testng/testng/5.8/tesng-5.8

5. If the component has a classifier, it is necessary to add the delimiter hyphen after the 4th item plus classifier,org/testng/testng/5.8/tesng-5.8-jdk5

6. Check the extension of the component, if extension exists, add a period separator and extension, and extension is determined by packing,org/testng/testng/5.8/ Tesng-5.8-jdk5.jar

Here we understand the details of MAVEN for component storage.

Categories of Maven Warehouses:

There are only two categories of Maven repositories: 1. Local warehouses 2. Remote warehouses, which are divided into 3 types in the remote repository: 2.1 Central warehouse 2.2 other public libraries

1. The local repository, as its name implies, is where Maven stores the widget locally.

Note: Maven's local repository is not created after Maven is installed, it was created the first time the MAVEN command was executed

The default location for the MAVEN local repository: either Windows or Linux, there is a. m2/repository/repository directory in the user's directory, which is the default location for the MAVEN repository

How to change the location of the default local repository for maven: A new element is introduced here:Localrepository, which is present in Maven's Settings.xml file

1.1 Changing the configuration user-scoped local warehouse: Create the settings.xml file in the/.m2/directory first , and then in ~/.m2/settings.xml, set the value of the localrepository element to the desired warehouse address

[HTML]View PlainCopy

1. <settings>
2. <localrepository>d:\maven_new_repository</localrepository>
3. </Settings>

At this point, MAVEN's local warehouse address becomes D:\maven_new_repository, note: The configured MAVEN local repository is user-scoped.

1.2 Changing the local warehouse that configures global scope: change configuration in M2_home/conf/settings.xml, change configuration method as above

Note: All users will be affected after this change, and if Maven is upgraded, all configurations will be cleared, so copy and back up the m2_home/conf/settings.xml file in advance

Therefore, it is generally not recommended to configure global Settings.xml

2. Remote Storage

2.1 When it comes to remote warehouses starting with the core central repository, the central repository is the default remote repository, and when Maven installs, it comes with the configuration of the central warehouse.

In Maven's aggregation and inheritance we said that all MAVEN projects would inherit the Super Pom, specifically the pom we call the Super Pom.

[HTML]View PlainCopy

2. <repositories>
4. <repository>
6. <ID>central</ID>
8. <name>central Repository</name>
10. <URL>http://repo.maven.apache.org/maven2</url>
12. <layout>default</layout>
14. <snapshots>
16. <enabled>false</enabled>
18. </Snapshots>
20. </repository>
22. </repositories>

The central repository contains the vast majority of popular open source Java artifacts, as well as source code, author information, SCM, information, license information, and so on. In general, simple Java project-dependent artifacts can be downloaded here to

2.2

Server is a special remote warehouse, which is set up in the local area network of the warehouse services, the Remote Storage Agent WAN on the network for MAVEN users within the LAN to use. When Maven needs to download the widget, it requests from the server, and if the widget does not exist on it, it is downloaded from an external remote repository, cached on the database, and then served as a maven download request. We can also upload some artifacts that cannot be downloaded from an external repository.

A feature of the Maven:

1. Save your network bandwidth: Reduce the external bandwidth consumption caused by duplicate requests

2. Accelerate maven artifacts: If the project is configured with many external remote repositories, the build speed will be greatly reduced

3. Deploy third-party artifacts: When some artifacts cannot be obtained from an external warehouse, we can deploy these artifacts to internal repositories for use in internal MAVEN projects

4. Improve stability and control: when the internet is unstable, the Maven build becomes unstable, and some of the software also provides additional functionality

5. Reduce the load on the central warehouse: the number of requests from the MAVEN central warehouse is huge, and the configuration of the facility can significantly reduce the pressure on the central warehouse

Current major maven:

1.Apache of Archiva

2.JFrog of Artifactory

Nexus 3.Sonatype

Third, remote warehouse configuration

Configuring the Remote repository introduces new configuration elements:<repositories> <repository>

under the <repositories> element, you can declare one or more remote warehouses using the <repository> child element.

Example:

[HTML]View PlainCopy

2. <repositories>
4. <repository>
6. <ID>jboss</ID>
8. <name>jboss Repository</name>
10. <URL>http://repository.jboss.com/maven2/</url>
12. <releases>
14. <updatepolicy>daily</updatepolicy><!--never,always,interval N--
16. <enabled>true</enabled>
18. <checksumpolicy>warn</checksumpolicy><!--fail,ignore -
20. </releases>
22. <snapshots>
24. <enabled>false</enabled>
26. </Snapshots>
28. <layout>default</layout>
30. </repository>
32. </repositories>

<updatePolicy> element: Indicates the frequency of the update, the value is: Never, always,interval,daily, daily is the default value

<checksumPolicy> elements: A policy that represents the Maven check and quarantine file, warn as the default value

For security reasons, sometimes we want to authenticate the access to the remote repository, typically configuring the authentication information in Settings.xml:

[HTML]View PlainCopy

2. <span style="White-space:pre"> </span><servers>
4. <server>
6. <ID>same with repository ID in pom</ID>
8. <username>username</username>
10. <password>pwd</password>
12. </Server>
14. </Servers>

Note: The ID must match the ID of the repository element in the POM that requires authentication.

How to deploy a generated project to a remote warehouse

To do this, you also need to configure it in Pom, where a new element is introduced:<distributionmanagement>

Distributionmanagement contains 2 child elements: Repository and snapshotrepository, which represent the repository for the release build artifacts, which represents the snapshot version of the warehouse

Both elements require a configuration ID (the remote repository's unique identity), Name,url (which represents the address of the warehouse)

Deploying artifacts to a remote repository requires certification. Configuration Ibid.

Run correctly after configuration: mvn clean Deploy

Look at the snapshot correctly

Before we configured the POM, the configuration of the snapshot is very cautious, or rarely use the snapshot version, because it is also very unstable, very easy to bring our system unknown error, it is difficult to find. In fact, the snapshot version is not useless, the largest use of snapshots is used in the development process, especially when the module relies on, for example, AB two modules developed at the same time, a dependent on B, the development process AB are continuous integration development, continuous modification of pom files and construction works, This time, version synchronization becomes a big problem. This can be achieved with a snapshot.

In fact, during the release of the snapshot version, Maven automatically marks the widget with the current timestamp, and with this timestamp, we can find the latest snapshot version at any time, thus solving the problem of collaborative development just mentioned.

As for a how to check the update of B, just said at the time of configuration, there is an element in the snapshot configuration to control the frequency of checking for updates------updatepolicy

We can also force the MAVEN to check for updates using command line plus arguments:

MVN Clean Install-u

How exactly does Maven parse a component from a warehouse? ----MAVEN's mechanism for resolving dependencies from the warehouse

1. When the dependency range is system, MAVEN parses the widget directly from the local file system

2. After calculating the warehouse path based on the dependent coordinates, try to find the artifacts directly from the local warehouse, and if the corresponding artifacts are found, the resolution succeeds

3. In the case of a local repository where there are no corresponding artifacts, if the dependent version is the published build widget that is displayed, traverse all remote repositories, and then download using

4. If the dependent version is release or latest, the metadata for all remote warehouses is read based on the update policy, and after the corresponding metadata for the local warehouse is merged, the actual value of release or latest is computed, and then the local warehouse is checked based on this real value.

5. If the dependent version is snapshot, read the metadata for all remote warehouses based on the update policy, merge it with the corresponding metadata for the local warehouse, get the value of the latest snapshot version, and then check the local warehouse or download from the remote repository based on the value

6. If the last resolved component version is a snapshot of the timestamp format, copy the file in its timestamp format to the non-timestamp format and use the non-timestamp format widget

Note: Be sure to remember <release> <enabled> & <snapshot> <enabled>, as well as for snapshots

LATEST & Release is not recommended for POM dependency declarations, and LATEST & release is no longer supported in Maven3, and if the plug-in version is not set, the final version is the same as release.

Maven only resolves the most recent release builds.

MAVEN local warehouse and remote repository