Go Maven and Nexus Relationships

When you start using MAVEN, you'll always hear the word nexus, MAVEN, Nexus for a while, confused, what is Nexus, and why is it always mentioned with Maven?

Let's take a step-by-step look at it.

First, understand what Maven,maven used to do 1. Excellent building tools

With simple commands, you can complete a series of processes such as cleaning, compiling, testing, packaging, and deploying. At the same time, it has to be mentioned that Maven is cross-platform and can use the same commands, whether it's on Windows or Linux or Mac.

2. Dependency Management Tools

Project-dependent third-party open source class libraries can be introduced into the project in a way that relies on them. Instead of the way to first download a third-party jar and then add it to the project. In order to better solve the cooperative development of dependency increase, version inconsistency, version conflict, dependency bloated and other issues.

How is it implemented? Maven locates each component accurately by coordinate system, that is, the corresponding Java class library is found through coordinates.

3. Project Information management tools

Ability to manage project descriptions, developer lists, version control system addresses, licenses, and more scattered project information. In addition to direct project information, through MAVEN auto-generated sites, as well as some existing plugins, it is also easy to get project documents, test reports, static analysis reports, source code version, log reports and other valuable project information.

Second, MAVEN and Nexus

This question starts with the second use of MAVEN, relies on management, and introduces the jar into the project by specifying coordinates in the POM. So what is the process going through? Where do I find the jar? Where are the downloaded jars placed?

With this problem in place, you know the Nexus and maven relationship.

Where do I find the jar? Where is the jar where the project is stored? This leads to the concept of the warehouse, where Maven manages the various artifacts through the warehouse. Maven's warehouses are divided into local warehouses and remote warehouses.

When Maven looks for a widget based on coordinates, it first looks at the local repository, and if the local repository exists, it is used directly; if the artifact does not exist in the local repository, or if it is necessary to see if there is an updated artifact version, MAVEN will go to the remote repository to find the required artifacts and download them to the local repository for reuse.

When we get here, the answer to the question comes out.

First, Nexus is a remote repository, and we already know the role of remote repositories, as described in the previous section. In the remote repository, the default is the central warehouse, which is the remote repository that the MAVEN core comes with. Why don't we just use the central repository and why do we have to install the Nexus?

We look at the actual development of the project:

1. Some artifacts that cannot be downloaded from an external repository, such as internal projects, can also be deployed on a database for use by other dependent projects.

2. In order to save bandwidth and time, set up a private warehouse server in the LAN and use it to proxy all external remote repositories. When the local MAVEN project needs to download the component, the first request, if not, then go to the remote warehouse request, after downloading the component from the remote repository, the component is cached on the database. In this way, there is no internet connection in time, the whole project can be used normally because a large number of components have been cached. At the same time, it also reduces the load of the central warehouse.

Nexus is just one of those.

http://blog.csdn.net/liusong0605/article/details/25654811

Go Maven and Nexus Relationships