Shulou(Shulou.com)06/01 Report--

This article mainly explains "how to manage the version of maven". The content in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn how to manage the version of maven.

Maven private library

Building your own private warehouse within the company is the basis of all version management, without which everything is out of the question.

Without Nexus private server, all the components we need need to be downloaded locally through the central warehouse of maven or the third-party Maven repository, which will cause a lot of problems:

May be unable to download due to network problems (such as development of intranet environment)

It is a waste of everyone on the team to download repeatedly.

Modules developed by different people on the team are not easy to share with other members

At present, the mainstream solutions are based on NEXUS. The architecture is as follows:

I am not going to write about the installation process, there are more online you can find their own.

After the installation is complete, the interface looks like this (different versions may have different interfaces):

Maven-central: jar downloaded from a central warehouse or a third party is stored here

Maven-releases: the jar of the team's internal release

Maven-snapshots: the development version of jar within the team (more on this later)

Maven-public: combine the above three warehouses to provide services (mainly used in settings.xml)

Maven snapshot

Everything is not all right with the private key store. Just imagine this scenario, where An and B each develop a module. A's module needs to rely on B's module. B develops a version (such as 1.1.1) and then mvn:deploy to a private library, and A can directly reference it in its own POM.

Com.yi.develop

Develop_by_yi

1.1.1

After a while, B found out that there was a bug in the code, so he quickly fixed it and released the version 1.1.2 to the private library. The problem arises. First of all, if B forgets to tell An about this, A will always use a lower version of B module, which may bring fatal problems to the whole application. Second, even if B told A the news in time, A should also modify its own pom file to update. After B constantly update the version, A will constantly update the POM file. Is it troublesome?!

Maven has already helped you figure out a solution, which introduces the concept of a snapshot version. B named the version of the module developed by him as 1.1-snapshot, and A quoted it into his own project like this:

Com.yi.develop

Develop_by_yi

1.1-snapshot

B after each update is submitted to the private database, the SNAPSHOT will be changed to a timestamp of the current time. When dealing with the SNAPSHOT dependency, the jar,Maven will download the latest jar according to the timestamp. By default, the version of the snapshot is automatically updated once a day. If you need to refer to the latest dependent package in real time, you can use the-U parameter to force the update.

Mvn clean install-U maven version numbering scheme

The Maven version number adopts the general three-level rule:

[main version number]. [copy number]. [repair version number]

The major version number generally represents a major architectural change to the project

The minor version number generally refers to the addition or decrease of functions.

The repair version number generally represents bug fix

Thank you for your reading, the above is the content of "how to manage the version of maven". After the study of this article, I believe you have a deeper understanding of how to manage the version of maven, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.