Snapshot sources and precautions in maven

The dependency management of maven is based on version management. After maven2, the version management is refined into snapshot snapshot warehouse and release release warehouse. For the release version, for the artifact in the release state (that is, the dependent jar package), if the version number is the same, even if the components on our internal mirror server are newer than the local, maven will not actively download it. This also lays the groundwork for the emergence of snapshots.  Snapshot version, many people do not particularly understand why this thing appears, does its appearance help programming? Before snapshots appeared, our development process depended on others to develop a certain package. Usually maven would centrally manage these dependent packages. It would require others to package them into jars and put them on the mirror server. After setting dependencies in their own local pom.xml file, maven When compiling, dependencies are automatically downloaded from the mirror server. But if there is a dependency of the same version on the mirror server, maven will not download it. This is the vernacular version of the above text, so give an example to illustrate.

       

       For example, the core version that your project depends on is version 1.0.0. As a result, this version is still in the development process of the other party (called Xiaocai). He uses the maven command mvn install to package it into a jar and deploy it to the server. According to The version set by pom, you successfully downloaded the dependency package. But in the follow-up development process of Xiaocai, a fatal bug is found, so he will operate it again, then, even if the update of the server is what you need, you can only be anxious and shout to Xiaocai, "Your version, I can't update the dependencies. package, and send me a new version." Xiao Cai heard it, okay, then I will upgrade the version to version 1.0.1, and you downloaded the new version of the jar package through update dependencies. This kind of situation will appear cyclically, then you and Xiaocai are a little annoyed. Maven is a mouse that gets into the bellows and gets gas at both ends. Maven wants to develop a function so that both parties can upload and package and download to the latest development version by default. There is no need to modify the version number, otherwise after the development is completed, there will be a bunch of release versions on the server. With this idea, maven adds an epoch-making function, snapshot, so that the dependency version is 1.0.0-SNAPSHOT (note that it must be all uppercase), when there is an update on the server, it will be automatically downloaded to the local, saving a lot of, The communication time with Xiaocai has also reduced a lot of compilation errors caused by version problems.  The use of anything needs to follow its rules. Although snapshot is easy to use, if it is used improperly, it is easy to cause confusion. First of all, when developing a dependent jar package, pay attention to the difference in snapshot version numbers. You need a unified place to record the respective versions. In the case of a long development cycle, the release order of the version numbers is not in the order of the version numbers. The important thing is , everyone's development version number cannot be repeated. If you are also developing this core.jar, you depend on the local, and other people on the server have core.jar with the same version number on the server regularly, so the local jar is often overwritten by the version from the server, causing errors.

     

        To sum up, in the development phase, we can set the version of the public library as the snapshot version, and the dependent components refer to the snapshot version for development. After the snapshot version of the public library is updated, we do not need to modify the pom version number to download the new version. version, you can re-download the latest snapshot library by directly executing the relevant compilation and packaging commands in mvn, thus ensuring the development progress and quality.

1. mvn debugging information: for
example: mvn -X -e clean compile
-e: print error information.
-X: stands for debug mode.

2. If you use mirror in the setting, you will directly report the error that the corresponding jar cannot be found.
The original setting configuration:
<mirrors>  <mirror>  <id>Nexus</id>  <url>http://192.168.4.11/content/groups/public/</url>  <mirrorOf>*</mirrorOf>  </mirror > </mirrors> This is a problem, you can use -X -e to see the following information: [DEBUG] Repositories (dependencies): [Nexus (http://192.168.4.11/content/groups/public/ , releases) ] [DEBUG] Repositories (plugins)   : [Nexus (http://192.168.4.
       
           
           
           
       




   


Obviously public is only valid for release, not for snapshot. The solution only needs to define mirrortype to specify that it is valid for snapshot.
Change to:
<mirrors>  <mirror>  <id>Nexus</id>  <url>http://192.168.4.11/content/groups/public/</url>  <mirrorOf>*</mirrorOf>  </mirror>  <mirror>  <id>Nexus2</id>  <url>http://192.168.4.11/content/groups/public/</url>  <mirrorOf>public-snapshots</mirrorOf> // valid for snapshots  </mirror > </mirrors> <profiles> //Define public-snapshots profile  <profile>  <id>public-snapshots</id>  <repositories>  <repository>  <id>public-snapshots</id>
   
           
           
           
       
       
           
           
           
       



       
           
           
               
                   
                   
                   
                       
                   
                   
                       
                   
               
           
           
               
                   
                   
                   
                       
                   
                   
                       
                   
               
           
       
   

   
       
    


[DEBUG] Repositories (dependencies): [Nexus (http://192.168.4.11/content/groups/
public/, snapshots), central (http://repo1.maven.org/maven2, releases)]
[DEBUG] Repositories (plugins)   : [Nexus (http://192.168.4.11/content/groups/   
public/, snapshots), central (http://repo1.maven.org/maven2, releases)]

Done!
I always feel that the above method is a bit lame!
The official configuration of sonatype is as follows: For
another configuration method, see: http://www.sonatype.com/books/nexus-book/reference/maven-sect-single-group.html

3. Note: maven will automatically select from the repository Check the latest version of the snapshot version of module A, and download it when an update is found. By default, maven checks for updates once a day (controlled by the updatePolicy configured by the repository), and users can also use the command -U parameter to force maven to check for updates, such as maven clean install -U.
Element updatePlocy description: used to configure the frequency of maven checking updates from the remote repository, the default value is daily, which means checking once a day.