Maven Warehouse, mirroring

1, the storage jar package positioning

Any dependency, plug-in, or project-built output in the MAVEN world can be called artifacts, and any one component has a coordinate as its unique identity.

The coordinates are: group, Artifactid, version; Depending on the coordinates, it is possible to define its unique storage path in the warehouse, so it can be referenced in the project.

<groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.10</version >

2. Maven Warehouse principle

The MAVEN repository is based on simple file system storage, so long as there are no related files found in the file system, the dependencies do not exist, so it is easy to find a specific dependency in the local repository.

3, Warehouse classification information (local warehouse, remote warehouse)

1) The local repository is the file system on our own machine, so he is the only one, when the project is built, it first finds dependencies on the local repository and then looks for the remote repository if there is no local dependency.

2) remote warehouse refers to all other warehouses that are non-local, central warehouses, and so on are remote warehouses. If the local repository does not have the artifacts required to build the project, you will be downloading from the remote repository, but if you do not have the remote repository, you will get an error on the project.

4. Local Warehouse Settings

<localrepository>d:\program files\apache-maven-3.2.2-repository</localrepository>

When the installation has a Conf/settings.xml file, this file when the global control file, in addition, there is a C:\Users\Heweipo\.m2 There will also be a settings.xml file, which represents a personal local configuration file, however, we use Eclipse by default with this settings.xml file, can be modified by the following:

5. Central Warehouse

Maven must know at least one of the available remote repositories to download to the required artifacts when executing the MAVEN command. The central repository is such a default remote repository where the MAVEN installation file comes with a remote repository location

Http://repo.maven.apache.org/maven2

The configuration of the specific central repository in the Settings.xml file is as follows:

    <repositories>            <repository>                      <id>central</id>                      <name>Central  repository</name>                                <url >http://repo.maven.apache.org/maven2</url>                                 <layout>default</layout>                                 <snapshots>                          <enabled>true</enabled>                           <updatePolicy>always</updatePolicy>                           <checksumPolicy>always</checksumPolicy>                      </snapshots>              </repository>      </repositories> 

6.

The server is a special remote warehouse, which is set up in the local area network, the Remote Storage agent on the WAN, for MAVEN users in the LAN. When Maven needs to download the widget, it requests from the server, if there is no modification widget on the server, it is downloaded from the external remote repository, cached on the database, and then served for the MAVEN download request, in addition, For third-party jars that cannot be downloaded from the repository (JDBC driver) can be uploaded locally to the client for download.

The main advantages are:

1) Save External network broadband

2) Accelerate Maven build

3) Deploy third-party artifacts

4) Improve stability, enhance control: The reason is the external network instability

5) Reduce the load on the central warehouse: because the central warehouse access is too large

7, remote Warehouse certification

Sometimes logging in to a remote repository requires a user name and password for authentication, so remote warehouse authentication is required. Unlike configuring the authentication information and configuring the warehouse information, the warehouse information can be directly configured in the Pom file, but the authentication information must be configured in the settings.xml file for security purposes. Of course, we can configure the warehouse information in the settings.xml, the disadvantage is that a good dynamic control of the warehouse, but generally will not change the warehouse, we are generally unique local.

<server> <id>deploymentRepo_releases</id> <username>repouser</username> <p Assword>repopwd</password> </server>

It is important to note that the ID represents the ID of a repository element configuration.

8. Remote Warehouse Deployment

  <distributionManagement>    <repository>         <id>deploymentRepo_releases</id>         <name>Nexus Release Repository</name>         <url>http://localhost:8081/nexus/content/repositories/releases/</url>     </repository>    <snapshotRepository>         <id>deploymentRepo_snapshots</id>         <name>Nexus Snapshot Repository</name>         <url>http://localhost:8081/nexus/content/repositories/snapshots/</url>     </snapshotrepository></distributionmanagement> 

The version we developed can deploy the project to the corresponding one via MVN deploy for the reasons why the release and snapshot versions are separated primarily for the purpose of facilitating post-project maintenance and collaborative development at that time. For example, the release must be a stable version, but he may not have so much functionality, for some customers who require stability can give him a release version, but for the snapshot version, is a development of the version, this version may be dependent on another project at any time, if he needs my functionality I will do code submission, That is, to deploy to a single-car, however, this time Maven will take my snapshot version of a timestamp added after the snapshot version, the other people rely on the snapshot version will be automatically updated to the latest snapshot version, these are MAVEN help us to complete, we just need to submit the project.

9. Mirror

If warehouse X can provide all the content stored in the warehouse Y, then you can assume that X is a mirror of Y, and in some cases mirroring can improve project build efficiency.

Configuring Mirroring in Settings.xml

<mirrors> <mirror> <id>mirrorId</id> <mirrorOf>repositoryId</mirrorOf> <name>human readable name for this mirror.</name> <url>http://my.repository.com/repo/path</ur L> </mirror> </mirrors>

Mirroring means that when you access the Mirrorof repository, you go to the corresponding mirror URL and request the corresponding resource. General images are used in conjunction with a. Because the client can proxy any external public repository (including a central warehouse), for MAVEN users within the organization, using a single-use address is tantamount to using all the external warehouses needed, which can be configured to a configuration of the database, simplifying the configuration of Maven itself. In this case, any required artifacts can be obtained from a single database, which is the mirror of all the warehouses. The image of the monkey is configured as follows:

<mirrors> <mirror> <id>mirrorId</id> <mirrorOf>*</mirrorOf> <name >human readable Name for this mirror.</name> <url>http://my.repository.com/repo/path</url> &L T;/mirror> </mirrors>

10 in-Warehouse Jar pack Search

1) Warehouse Search:

2) Central Warehouse

http://repo1.maven.org/maven2/

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

http://repository.sonatype.org/content/groups/public/

Maven Warehouse, mirroring