Maven detailed warehouse ------ local warehouse, remote warehouse

In Maven, any dependency, plugin, or output of a project build can be called an artifact.
Maven stores the shared components of all projects in a unified location, which we call a repository. (The warehouse 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, and
interprets the storage path of Maven in the warehouse:
1. Prepare the path based on groupId, Converting the period separator into a path separator is to convert "." into "/"; example: org.testng --->org/testng
2. Prepare the path based on the artifactId and connect the artifactId to the back: org/testng/ testng
3. Use the version to prepare the path, and connect the version to the back: org/testng/testng/5.8
4. Connect the artifactId to the version with the separator hyphen to the back: org/testng/testng/5.8/tesng-5.8
5. Judgment If the component has a classifier, add a separator hyphen after the fourth item and add the classifier, org/testng/testng/5.8/tesng-5.8-jdk5
6. Check the extension of the component, if the 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.
Classification of Maven repositories:
There are only two types of maven warehouses: 1. Local warehouses 2. Remote warehouses, which are divided into 3 types in remote warehouses: 2.1 Central warehouse 2.2 Private server 2.3 Other public warehouses
1. Local warehouse, as the name suggests, is where Maven stores components locally place.
Note: Maven's local repository is not created after maven is installed. It is created when the maven command is executed for the first time
. The default location of the maven local repository: whether it is Windows or Linux, it is available in the user's directory. A repository directory of .m2/repository/, which is the default location of the Maven repository.
How to change the location of the default local repository for maven: Here we introduce a new element: localRepository, which exists in the settings.xml file of maven
1.1 Change Configure a user-scoped local repository: first create a settings.xml file in the /.m2/ directory, and then in ~/.m2/settings.xml, set the value of the localRepository element to the desired repository address

<settings>  
    <localRepository>D:\maven_new_repository</localRepository>  
</settings>

 At this time, the address of maven 's local repository becomes D:\maven_new_repository . Note: The local repository of maven configured at this time belongs to the user scope.

 

1.2 Change the local warehouse of the configuration global scope: change the configuration in M2_HOME/conf/settings.xml , the method of changing the configuration is the same as above

Note: After this change, all users will be affected, and if maven is upgraded, all configurations will be cleared, so copy and backup the M2_HOME/conf/settings.xml file in advance

Therefore: In general, it is not recommended to configure global settings.xml

2. Remote warehouse

2.1 When it comes to remote warehouses, 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 that contains the following configuration is called the super pom.

<repositories>  
    <repository>  
      <id>central</id>  
      <name>Central Repository</name>  
      <url>http://repo.maven.apache.org/maven2</url>  
      <layout>default</layout>  
      <snapshots>  
        <enabled>false</enabled>  
      </snapshots>  
    </repository>  
  </repositories>

 

 

The central repository contains most of the popular open source Java components, as well as source code, author information, SCM, information, license information, etc. In general, the components that simple Java projects depend 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 local area network. The private server acts as a remote warehouse on the WAN for Maven users in the local area network. 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 will be downloaded from an external remote repository, cached on the private server, and then serve Maven's download request. We can also upload some components that cannot be downloaded from external repositories to the private server.

Features of Maven private server:

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

2. Speed ​​up Maven artifacts: If the project is configured with many external remote repositories, the build 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 use by internal maven projects

4. Improve stability and enhance control: When the Internet is unstable, the maven build will also become unstable, and some private server software also provides other functions

5. Reduce the load of the central warehouse: The number of requests from the maven central warehouse is huge, and configuring private servers can also greatly reduce the pressure on the central warehouse

The current mainstream maven private server:

1. Apache Archiva

2. JFrog's Artifactory

3. Sonatype's Nexus

3. Remote warehouse configuration

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

Under the <repositories> element,   one or more remote repositories can be declared using the <repository> sub-element.

example:

<repositories>  
        <repository>  
            <id>jboss</id>  
            <name>JBoss Repository</name>  
            <url>http://repository.jboss.com/maven2/</url>  
            <releases>  
                <updatePolicy>daily</updatePolicy><!-- never,always,interval n -->  
                <enabled>true</enabled>  
                <checksumPolicy>warn</checksumPolicy><!-- fail,ignore -->  
            </releases>  
            <snapshots>  
                <enabled>false</enabled>  
            </snapshots>  
            <layout>default</layout>  
        </repository>  
    </repositories>  

 

<updatePolicy> element: Indicates the update frequency, the values ​​are: never, always, interval, daily, daily are the default values

 

<checksumPolicy> element: indicates the policy for maven to check and verify files, warn is the default value

出于安全方面的考虑，有时我们要对远程仓库的访问进行认证，一般将认证信息配置在settings.xml中：

<span style="white-space:pre">    </span><servers>  
        <server>  
            <id>same with repository id in pom</id>  
            <username>username</username>  
            <password>pwd</password>  
        </server>  
    </servers

 

注：这里的id必须与POM中需要认证的repository元素的Id一致。

 

 

如何将生成的项目部署到远程仓库

完成这项工作，也需要在POM中进行配置，这里有新引入了一个元素：<distributionManagement>

distributionManagement包含了2个子元素：repository和snapshotRepository, 前者表示发布版本构件的仓库，后者表示快照版本的仓库

这两个元素都需要配置 id(该远程仓库的唯一标识)，name，url(表示该仓库的地址)

向远程仓库中部署构件，需要进行认证。配置同上

配置正确后运行： mvn clean deploy

正确的看待快照

之前我们在配置pom的时候，对于快照的配置都很谨慎，或者说很少用快照的版本，原因是它还很不稳定，极容易给我们的系统带来未知的错误，让我们很难查找。其实快照版本也并不是一无是处，快照最大的用途是用在开发的过程中，尤其是有模块依赖的时候，比如说AB两个模块同时开发，A依赖于B，开发过程中AB都是持续集成的开发，不断的修改POM文件和构建工程，这时候版本同步就成了一个很大的问题。使用快照就可以达到这一目的。

其实在快照版本在发布的过程中，Maven会自动为构件以当前时间戳做标记，有了这个时间戳，我们就可以随时找到最新的快照版本，这样也就解决刚才说的 协作开发的问题。

至于A如何检查B的更新，刚刚在讲配置的时候说过，快照配置中有一个元素可以控制检查更新的频率------updatePolicy

我们也可以使用命令行加参数的形式强制执行让maven检查更新：

mvn clean install-U

 

maven到底是如何从仓库中解析构件的呢？----maven从仓库解析依赖的机制

1. 当依赖的范围是system的时候，Maven直接从本地文件系统解析构件

2. 根据依赖坐标计算仓库路径后，尝试直接从本地仓库寻找构件，如果发现相应构件，则解析成功

3. 在本地仓库不存在相应的构件情况下，如果依赖的版本是显示的发布版本构件，则遍历所有的远程仓库，发现后下载使用

4. 如果依赖的版本是RELEASE或LATEST, 则基于更新策略读取所有远程仓库的元数据，将其于本地仓库的对应元数据合并后，计算出RELEASE或者LATEST的真实值，然后基于这个真实值检查本地仓库

5. 如果依赖的版本是SNAPSHOT， 则基于更新策略读取所有远程仓库的元数据， 将其与本地仓库的对应元数据合并后，得到最新快照版本的值，然后基于该值检查本地仓库或从远程仓库下载

6. 如果最后解析到的构件版本是时间戳格式的快照，则复制其时间戳格式的文件 至 非时间戳格式，并使用该非时间戳格式的构件

注：一定要记得<release>  <enabled>     &    <snapshot>  <enabled> ，对于快照也是一样

在POM的依赖声明的时候不推荐使用LATEST & RELEASE, 在Maven3中也不再支持在插件配置中使用LATEST & RELEASE， 如果不设置插件版本，那么最终版本和release一样，

maven只会解析最新的发布版本构建。