"Maven combat" learning summary (4)-warehouse

       In the last article, we introduced the logical representation of Maven components-coordinates and dependencies. This article will introduce the physical representation of components in Maven-the warehouse. Before the emergence of Maven, we generally have a lib folder under each project, which stores all the components that the project depends on, then the problem comes, each project depends on the same component, these identical and duplicate components are scattered in different Of projects occupy disk space and are difficult to manage. Based on the coordinate mechanism, Maven can store the components shared by various projects in a unified manner. This unified location is the warehouse.

       The corresponding relationship between the storage path of the component and the Maven coordinates is: groupId / artifactId / version / artifactId-version.packaging. The Maven warehouse is based on a simple file system storage, so we can easily find related files and locate problems when we encounter problems.

Sources of warehouse components: 1. Download from remote warehouse 2. Clean install to build the project and output to the warehouse


Classification of Maven warehouse

1. Local:

         Default local repository path-user directory / .m2 / repository

         Modify path configuration

        <settings>

                <localRepository>D:\java\repository\</localRepository>

         </settings>

2. Remote (central warehouse / private server / other public warehouse)

        When Maven searches for a component, it first determines whether the local warehouse exists, and returns if it exists. If it does not exist, it will go to the remote warehouse to find it, and then load it into the local warehouse, and then use it. It includes the following types:

        (1) Central warehouse: Maven's own remote warehouse contains most of the open source components, which makes Maven "out of the box"

                http://repo1.maven.org/maven2 (see $ M2_HOME / lib / maven-model-builder-3.0.jar --org / apache / maven / model / pom-4.0.0.xml for details)

        (2) Private server: The remote warehouse agent set up in the local area network can reduce the bandwidth occupation of accessing the external network, speed up the download of components, and reduce the access pressure of the central warehouse. You can also deploy internal project generation components to private servers for use by other projects.

        (3) Other public warehouses:

                http://download.java.net/maven/2/, 

                http://repository.jboss.com/maven2/


Remote warehouse configuration

        Configuration in POM

                Remaining problem:

                        How to configure multiple remote warehouses?

                        Component version indication, reminder when checking for updates?

         1. Certification

                Configured in settings.xml: <servers>

        2. Deploy to a remote warehouse

                Configuration project pom.xml: <distributionManagement>

                mvn clean deploy

         Snapshot version

                 If there is no snapshot version, when multiple people collaborate, different modules are implemented and there is a dependency relationship between modules. At this time, in order to realize the call between modules, you need to specify the version number, but because both modules are in development, they are not stable. The dependent modules will change frequently.

                From the perspective of the relying party, the preferred solutions are: 1. Move out the dependent module code and compile locally; 2. Specify a fixed version, and update it after each build since you need to manually delete it; 3. Both parties keep changing versions, but this It also means that every change needs to be modified in cascade, and there are multiple places.

                With the concept of snapshot version, the above problem can be solved well. When Maven builds the snapshot version of the component, it will automatically add a timestamp. When the relying party component will check the update of the snapshot version according to the strategy during the build process, if there is a new version, the latest version of the dependency will be used for the dependent build activity. You can also execute mvn clean install-U to force check for updates


                Mirror configuration

                        <mirrors>

                Warehouse search service

                        http://www.mvnbrowser.com/http://mvnrepository.com/ https://repository.sonatype.org、http://www.jarvana.com/jarvana

                       

小结

        本文介绍了Maven仓库的概念以及布局,分类及其使用上的配置,同时解释了快照的概念--方便协同开发时的版本控制,最后也汇总了一些仓库搜索服务,方便日常开发。

发布了159 篇原创文章 · 获赞 225 · 访问量 21万+

Guess you like

Origin blog.csdn.net/lyg673770712/article/details/51029715