Explain the local warehouse and remote warehouse of Maven warehouse in detail

What is Maven warehouse

When Maven is not used, for example, we used to build projects with ant. In the project directory, we often see a subdirectory named / lib, where various third-party dependent jar files are stored, such as log4j jar，junit. Jar, wait.

For each project, you need to create such a / lib directory and then copy a pair of jar files, which is an obvious repetition. Repetition is always the starting point of a nightmare. Multiple projects do not share the same jar file, which will not only waste disk resources, but also make version consistency management difficult.

In addition, if you use version management tools, such as SVN (you don't use version management tools? Try SVN now, which can help you solve many headaches), you need to submit a large number of jar files to the code base, but the version management tools are not good at dealing with binary files.

Maven warehouse is to place all jar files (war, zip, POM, etc.), all Maven projects can obtain their required dependent jars from the same Maven warehouse, which saves disk resources. In addition, because all jars in Maven warehouse have their own coordinates, which tell Maven its group ID, component ID, version, packaging method, etc., Maven projects can easily manage dependent versions Manage. You no longer need to submit jar files to SCM warehouse. You can establish an organization level Maven warehouse for all members to use.

In short, Maven warehouse can help us manage components (mainly jars).

In maven, the output of any dependency, plug-in or project construction can be called a component.

Maven stores the shared components of all projects in a unified location, which is called the warehouse. (the repository is where dependencies and plug-ins are stored)

Any component has a unique coordinate. Maven defines the unique storage path of the component in the warehouse according to this coordinate,

Interpret Maven's storage path in the warehouse:

1. Prepare the path based on groupid, and convert the period separator to the path separator, that is, "." Convert to "/"; example： org. testng --->org/testng

2. Prepare the path based on artifact ID and connect artifact ID to the following: 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 separator hyphen: org / TestNG / TestNG / 5.8 / testng-5.8

5. If the component has a classifier, add the separator hyphen after item 4, and then add the classifier, org / TestNG / TestNG / 5.8/testng-5.8-jdk5

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

Here we understand Maven's details on component storage.

Classification of Maven warehouse:

Maven's warehouse has only two categories: 1 Local warehouse 2 Remote warehouse is divided into three types: 2.1 central warehouse 2.2 private server 2.3 other public warehouses

1. The local warehouse, as the name suggests, is where Maven stores components locally.

Note: the local warehouse of Maven will not be created after Maven is installed. It is only created when the Maven command is executed for the first time

The default location of Maven local warehouse: whether it is windows or Linux, there is one in the user's directory M2 / repository /, which is the default location of Maven warehouse

How to change the location of Maven's default local repository: Here we need to introduce a new element: localrepository, which exists in Maven's settings XML file

1.1 change the local warehouse of the configuration user range: first at / M2 / create settings in the directory XML file, and then in ~ / m2/settings. XML, set the value of the localrepository element to the desired warehouse address

At this time, Maven's local warehouse address becomes D: \ Maven_ new_ Repository, note: the local repository of Maven configured at this time belongs to the user scope.

1.2 change the configuration of global local warehouse: in M2_ HOME/conf/settings. Change the configuration in XML. The method of changing the configuration is the same as above

Note: after this change, all users will be affected, and if Maven upgrades, all configurations will be cleared, so copy and backup m2 in advance_ HOME/conf/settings. XML file

Therefore, it is generally not recommended to configure global settings xml

2. Remote warehouse

2.1 When it comes to remote warehouse, start with the core central warehouse. The central warehouse is the default remote warehouse. When Maven is installed, it comes with the configuration of the central warehouse

In the aggregation and inheritance of maven, we said that all Maven projects will inherit the super POM. Specifically, the POM including the following configuration is called the super POM

The central repository contains most popular open source Java components, as well as source code, author information, SCM information, license information, etc. Generally speaking, the components that a simple java project depends on can be downloaded here

2.2 private server

Private server is a special remote warehouse. It is a warehouse service set up in the LAN. Private server acts as a remote warehouse on the WAN for Maven users in the LAN. When Maven needs to download a component, it requests it from the private server. If the component does not exist on the private server, it downloads it from an external remote warehouse, caches it on the private server, and then provides services for Maven's download request. We can also upload some components that cannot be downloaded from the external warehouse to the private server.

Maven private server features:

1. Save your own external bandwidth: reduce the external bandwidth consumption caused by repeated requests

2. Accelerate Maven components: if the project is configured with many external remote warehouses, the construction speed will be greatly reduced

3. Deploy third-party components: when some components cannot be obtained from external warehouses, we can deploy these components to internal warehouses (private servers) for internal Maven projects

4. Improve stability and control: when the Internet is unstable, Maven construction will become unstable. Some private server software also provides other functions

5. Reduce the load of the central warehouse: the number of requests for Maven central warehouse is huge. Configuring private servers can also greatly reduce the pressure of the central warehouse

Current mainstream Maven private servers:

1. Archiva of Apache

2. Jfrog's artifact

3. Nexus of sonatype

3、 Remote warehouse configuration

Configuring the remote repository will introduce a new configuration element: < repositories > < repository >

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

example:

< updatepolicy > element: indicates the update frequency. The values are: never, interval, daily. Daily is the default value

< checksumpolicy > element: indicates the policy of Maven checking and verifying files. Warn is the default value. For security reasons, sometimes we need to authenticate the access to the remote warehouse. Generally, the authentication information is configured in settings In XML:

Note: the ID here must be consistent with the ID of the repository element to be authenticated in POM.

How to deploy the generated project to a remote warehouse

To complete this work, you also need to configure in POM. Here is a new element: < Distribution Management >

Distribution management includes two sub elements: repository and snapshot repository. The former represents the repository of release version components, and the latter represents the repository of snapshot versions

Both elements need to be configured with ID (the unique identifier of the remote warehouse), name and URL (the address of the warehouse)

Deploying components to a remote warehouse requires authentication. The configuration is the same as above

Run after the configuration is correct: MVN clean deploy

Look at snapshots correctly

Previously, when configuring POM, we were very cautious about the snapshot configuration, or rarely used the snapshot version, because it is still very unstable, which is very easy to bring unknown errors to our system, making it difficult for us to find. In fact, the snapshot version is not good for nothing. The biggest use of snapshot is in the development process, especially when there are module dependencies. For example, AB and a are developed at the same time, and a depends on B. AB is continuously integrated during the development process, constantly modifying POM files and construction projects. At this time, version synchronization has become a big problem. This can be achieved using snapshots.

In fact, during the release of the snapshot version, Maven will automatically mark the component with the current timestamp. With this timestamp, we can find the latest snapshot version at any time, so as to solve the problem of collaborative development just mentioned.

As for how a checks the update of B, I just said when talking about the configuration that there is an element in the snapshot configuration that can control the frequency of checking the update - updatepolicy. We can also use the command line plus parameters to force Maven to check the update: MVN clean install-u

How does Maven parse components from the repository---- Maven's mechanism for resolving dependencies from the repository

1. When the dependent scope is system, Maven directly parses components from the local file system

2. After calculating the warehouse path according to the dependent coordinates, try to find the components directly from the local warehouse. If the corresponding components are found, the resolution is successful

3. When there is no corresponding component in the local warehouse, if the dependent version is the displayed released version component, traverse all remote warehouses and download it for use after discovery

4. If the dependent version is release or latest, read the metadata of all remote warehouses based on the update policy, merge the corresponding metadata of the local warehouse, calculate the real value of release or latest, and then check the local warehouse based on this real value

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

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

Note: be sure to remember < release > < enabled > & < snapshot > < enabled >, and the same is true for snapshots

Last & release is not recommended for POM dependency declaration, and it is no longer supported in Maven 3 to use last & release in plug-in configuration. If the plug-in version is not set, the final version is the same as release,

Maven only parses the latest release build.

The above is the whole content of this article. I hope it will be helpful to your study, and I hope you can support programming tips.