Maven's (v) Maven Warehouse

Local Warehouse

One of Maven's most prominent features is Jar package management, which, once the project needs to rely on which jar packages, can be configured in Maven's Pom.xml, the jar package will automatically introduce the project catalog. For the first time, it will be amazing, so let's explore how it works.

First of all, these jar bags are certainly not the children who have no father or mother, they have come, there are places. Places where these jar packages (and plugins, etc.) are stored centrally are called warehouses (Repository).

No matter where these jar packages come from, they must be stored on their own computers before your project can reference them. Similar to the computer There is a inn, dedicated to the guests from afar, this inn is called the local warehouse .

For example, the project needs to rely on Spring-core this jar package, in pom.xml after the declaration, MAVEN will first find in the local warehouse, if found to do well, automatically introduce the project's dependent Lib library. But what if I can't find it? In fact, this happens often, especially when the first use of MAVEN, the local warehouse is definitely empty, this time rely on Maven to the Avatar, to the remote warehouse to download.

Remote Warehouse

When it comes to remote warehouses, starting with the core central repository, the central repository is the default remote repository, and when Maven installs, the default central warehouse address is http://repo1.maven.org/maven2/, which is managed by the MAVEN community, Contains the vast majority of popular open source Java components, as well as source code, author information, SCM, information, license information and so on. In general, simple Java project-dependent artifacts can be downloaded here. The MAVEN community provides a central repository for search addresses: http://search.maven.org/#browse, all available library files can be queried.

In addition to the central warehouse, there are many other public remote warehouses, such as the central warehouse of the Mirror warehouse . All over the world from the central warehouse to request resources, exhausted the baby, so there are many central warehouses around the world a mirror warehouse. A mirrored warehouse can be understood as a copy of the warehouse, and resources are updated periodically from the original warehouse to maintain consistency with the original warehouse. Artifacts that can be found from the warehouse can also be found from the mirrored warehouse, directly accessing the mirrored warehouse, faster and more stable.

In addition, there are a lot of different public warehouses, if necessary can be found online, such as the Apache snapshots Warehouse, including from the Apache Software Foundation snapshot version.

In practice, the MAVEN default central repository is not normally used, and now the industry's most widely used warehouse address is: http://mvnrepository.com/, Faster, more complete, and more stable than the default central warehouse, who knows who to use.

Here is the information about the latest version of Spring-core in this warehouse:

Generally speaking, the company will set up a warehouse agent in the LAN through its own private server. It can be seen as a special remote repository that proxies the remote repositories on the WAN for use by MAVEN users in the LAN. When Maven needs to download the widget, it requests from the server, and if the widget does not exist, it is downloaded from the external remote repository, cached on the database, and then served as a maven download request.

There are many benefits to Maven:

1. You can upload the company's private jar package and the components that cannot be downloaded from the external warehouse to the enterprise for internal use;

2. Save your own external network bandwidth: Reduce the external bandwidth consumption caused by duplicate requests;

2. Accelerate Maven Build: If the project is configured with many external remote repositories, the build speed will be greatly reduced;

4. Improve stability and control: when the internet is unstable, the Maven build becomes unstable, and some of the software also provides additional functionality

The current mainstream maven has Apache Archiva, Jfrog artifactory, and Sonatype Nexus.

The above mentioned central warehouse, the central warehouse of the Mirror warehouse, other public warehouses, the remote warehouse is the category.

If Maven does not find what it wants in the local repository, it will automatically go to the remote repository specified in the configuration file and find it and download it to your local repository. If the remote warehouse can not find what you want, MAVEN is very angry, tired I ran a lap did not find, it must be your configuration is wrong, error to you see.

Configuration of the Warehouse

Warehouse configuration To do two things, one is to tell Maven where your local repository is, and the second is where your remote repository is.

As the name implies, Setting.xml's first node <localRepository> is the place to configure the local repository, needless to mention.

The configuration of the remote repository is somewhat complex because of the many ancillary features involved. Let's take a look at how to configure the remote repository in the case of the use of a virtual set. A slightly decent company will set up its own server, and if a company doesn't have a single one (regardless of whether it can't afford the servers or the technology), you might consider a job-hopping problem.

Now the most popular MAVEN warehouse manager is the famous nexus (pronunciation [? n?ks?s], meaning "center, armature" in English), which greatly simplifies the maintenance of its internal warehouses and access to external warehouses. With the Nexus, you have full control over every artifact that is accessed and deployed in the warehouse you maintain in just one place. Nexus is a set of "out-of-the-box" systems that do not require a database, which organizes data using the file system plus lucene.

As for the Nexus How to deploy, how to maintain the warehouse, as a developer does not need to care, just need to write the LAN address of the Nexus to Maven local configuration file. The specific configuration method is as follows:

1. Set the image

<mirrors><mirror>       <!--Unique identifier for this image. The ID is used to distinguish between different mirror elements. -       <id>nexus</id>       <!--mirror name, play the role of annotations, should be done to see the text to understand. You can not  configure       --<name>human readable name </name>       <!--  All warehouse artifacts are downloaded       from the mirror-- <mirrorOf>*</mirrorOf>       <!--LAN Address--       <url>http://192.168.0.1:8081/nexus/ Content/groups/public/</url></mirror></mirrors>

Node <mirrors> Below you can configure multiple mirrors,<mirrorof> to indicate which warehouse is mirrored, using the wildcard character "*" in the previous example to indicate that it is an image of all warehouses, regardless of the number of remote repositories that are used locally. When you need to download artifacts, you request them from a.

If you want to set up a remote repository for mirroring only, use <mirrorOf> to specify the ID of the remote repository.

2. Set up remote Warehouse

The remote repository settings are under the <profile> node:

<repositories><repository> <!--warehouse Unique identification--<id>repoid </id> <!--remote Warehouse name--&gt  ; <name>repoName</name> <!--remote Warehouse URL, if the warehouse is configured with a mirror, the URL here is meaningless, because any download request will be processed by the mirror warehouse. The premise is that the mirror (which is the set up) needs to ensure that any component in the remote repository can be downloaded to <url>http://......</url> <!--How to handle the download of the release version in the remote repository--<   Releases> <!--True or FALSE indicates whether the warehouse is open for downloading some type of widget (release, snapshot). -<enabled>false</enabled> <!--This element specifies how often updates occur. Maven compares the timestamps of local pom and remote Pom.  The options here are:--> <!--always, daily (default, daily), interval:x (where X is the time interval in minutes), or never (never). -<updatePolicy>always</updatePolicy> <!--What to do if Maven verifies that the artifact failed to validate the file:--> <!--Ignor E (Ignore), fail (failed), or warn (warning). -<checksumPolicy>warn</checksumPolicy> </releases> <!--How to handle the download of snapshot versions in remote warehouses, and the release version Configuration similar to <snapshots> <enabled/> <updatePolicy/> <checksumPolicy/> </snapshots> </repository> </repositories> 

Multiple remote warehouses can be configured and differentiated by <id>.

In addition, there is a remote repository with <repositories> side-by-side <pluginRepositories> nodes for configuring plugins.

The warehouse mainly stores two kinds of components. The first component is used as a dependency on other components, the most common being the various jar packages. This is the majority of the component types stored in the central warehouse. Another component type is a plug-in, and the Maven plugin is a special type of widget. For this reason, the plugin repository is independent of the other warehouses. The <pluginRepositories> node and the <repositories> node are not the same as the name of the root node, and the structure of the child element is exactly the same as the configuration method:

<pluginRepositories>      <pluginRepository>              <id/>             <name/>             <url/>              <releases>                    <enabled/>                    <updatepolicy/>                    <checksumpolicy/>             </ releases>                               <snapshots>                    <enabled/>                    <updatepolicy/>                    <checksumpolicy/ >             </snapshots>            </pluginRepository>             </pluginRepositories>

The remote repository has two sets of releases and snapshots configurations, and the Pom can take a different strategy for each type of artifact in each individual warehouse. For example, sometimes the support for snapshot version downloads is turned on for development purposes only, and <enabled > in <releases> is set to "false", and <snapshots> <enabled > is set to "True".

Because the remote repository is configured to hang under the <profile> node, if there are multiple <profile> nodes configured, there may be a variety of remote warehouse setup scenarios in which the scheme is enforced by its parent node <profile> Whether it is activated or not.

3. Set Publishing Permissions

In addition to providing the entire company with the Maven component download, there is also a very important function, is the resource sharing between developers.

A large project is often a sub-module development, there are dependencies between the various modules, such as a trading system, divided into the next single module, payment module, shopping cart module. Now the students who develop the next module need to call the interface in the payment module to complete the payment function, it is necessary to introduce some jar packages of the payment module into the local project in order to invoke its interface, and the students who develop the shopping cart module need to call the interface of the next single module to complete the order function. He will need to rely on certain jar packages for the next single module. These three modules are in continuous development, it is impossible to send their own source to support each other's dependence.

The solution is this way, each module completed a certain stage of the function, will provide external service interface into jar package, to the company's server, who want to use the function of the module, only need to declare in the Pom.xml file, maven will like to download the other jar package into your project.

In the development process, the component versions declared in the Pom are typically snapshot versions:

<dependency>      <groupId>com.yourCompany.trade</groupId>      <artifactid>trade-pay </artifactId>      <version>1.0.2-SNAPSHOT</version></dependency>

Each module is constantly uploading new jar packages, and if the local project relies on a snapshot version, MAVEN will download it instead of the previous version once it discovers that the jar package has a new release. For example, the payment module finds a bug in the test, fixes it, and then publishes the snapshot version to a single. And you just need to focus on the development of the next single module, the update of the payment module depends on MAVEN processing, do not need to care. Once you have developed the module to fix a bug, or add a new feature and other changes, only need to publish a snapshot version to the only one, who need to rely on your interface who will naturally go to download, you do not care.

After the establishment of the general non-certification can be accessed, but the risk is how big, you can imagine, such as a woman secretary accidentally put her and the boss of the nude leaked photos, the development of the students have no mind to work it ... Therefore, the permission settings are still necessary.

You will need to use the servers element in Setting.xml. It is important to note that the configuration information is in the Pom file, but the authentication information is in Setting.xml, because the Pom file is often submitted to the Code warehouse for all members to access, and Setting.xml is stored locally, which is safe.

In Settings.xml, configure users with the release release and snapshot version permissions:

The above ID is the ID of the server, not the user login ID, which matches the ID of the repository element in Distributionmanagement. Maven finds a matching publishing address based on the repository and distributionmnagement elements in the POM:

Note:the ID in the POM must match the configured ID in Setting.xml.

Then run the Maven cleandeploy command to deploy your own artifacts to other users in your organization (the difference between Maven clean deploy and maven clean install: Deploy deploys the component in a The install is to store the component in its own local repository).

Here are some people may have a question, all the warehouse settings are not already configured in the Setting.xml, why do you want to configure a URL in the Release Management node of POM?

Setting.xml is configured where you download artifacts, and here you configure where you want to publish the artifacts. Sometimes it is possible to download a warehouse and upload a warehouse that is two addresses, but in most cases, both are served by a single, that is, the two are the same address.

Maven's (v) Maven Warehouse