1. Configure the remote warehouse
In the usual development, we often don’t use the default central warehouse, warehouse in the middle of the default access speed is slow, perhaps many people visit, sometimes can’t satisfy the demand of our project, may need to some of the components of the project is not in the warehouse, and in other remote warehouse, such as JBoss Maven repository. At this point, you can configure the repository in pom.xml as follows:
1 <! -- Configure remote repository -->
2 <repositories>
3 <repository>
4 <id>jboss</id>
5 <name>JBoss Repository</name>
6 <url>http://repository.jboss.com/maven2/</url>
7 <releases>
8 <enabled>true</enabled>
9 <updatePolicy>daily</updatePolicy>
10 </releases>
11 <snapshots>
12 <enabled>false</enabled>
13 <checksumPolicy>warn</checksumPolicy>
14 </snapshots>
15 <layout>default</layout>
16 </repository>
17 </repositories>
Copy the codeRepository: Under the Repository element, you can use the Repository child to declare one or more remote repositories.
Id: the unique ID of the repository declaration. In particular, Maven’s built-in central repository uses the ID Central. If other repository declarations use this ID, the configuration of the central repository will be overwritten.
Name: the name of the warehouse, so that we can intuitively and conveniently know which warehouse is, for the time being, we have not found other too big meaning.
Url: Refers to the address of the repository. Generally, this address is HTTP based. Maven users can open the repository address in a browser to browse the artifact.
Releases and snapshots: Controls Maven’s access to releases and snapshots. Note the enabled subelement. In this example, the enabled value of Releases is true, indicating that the release version download of the JBoss repository is enabled, and the enabled value of snapshots is false, indicating that the release version download of the JBoss repository is disabled. According to this configuration, Maven will only download the release artifacts from the JBoss repository, not the snapshot artifacts.
Layout: The element value default indicates that the warehouse layout is the default layout for Maven2 and Maven3, not Maven1. Maven1 layout is almost never used.
Others: For releases and snapshots, in addition to enabled, they contain two other child elements, updatePolicy and checksumPolicy.
The updatePolicy element is used to configure how often Maven checks for updates from distant repositories. The default value is daily, which means Maven checks once a day. Other available values include: never- never checks for updates; Always – Checks for updates every build; Interval: X- Checks for updates every X minutes (X is any integer).
The checksumPolicy element configures Maven’s policy for checking checksum files. When a build is deployed to the Maven repository, the corresponding validations and files are deployed together. Maven validates the checksum file when downloading the component. If checksum-validation fails, Maven will print a warning message during build execution when checksumPolicy is set to the default WARN. Other available values include: fail-Maven encounters checksum errors and the build fails; Ignore – Causes Maven to completely ignore checksum errors.
2. Authenticate the remote warehouse
Most public remote repositories can be accessed directly without authentication, but we often set up our own Maven remote repository during development. For security reasons, we need to provide authentication information to access such remote repositories. Configuring authentication information is different from configuring remote repositories. Remote repositories can be configured directly in pom.xml, but authentication information must be configured in settings.xml. This is because POM tends to be submitted to the code repository for all members to access, whereas settings.xml is generally native only. Therefore, it is safer to configure authentication information in settings.xml.
1 <settings>2 2... 3 3<! -- Configure remote warehouse authentication information -->
4 4 <servers>
5 5 <server>
6 6 <id>releases</id>July 7<username>admin</username>
8 8 <password>admin123</password>
9 9 </server>
10 10 </servers>11 11... 12 12</settings>
Copy the codeIn the code above we configured a remote repository authentication information with an ID for Releases. Maven configures the repository authentication information using the Servers element and its child element server in settings. XML. The user name and password for authentication are admin and admin123 respectively. The key here is the ID element. The ID of the server element in settings. XML must be exactly the same as the ID of the Repository element in Pom.xml that needs to be authenticated. It is this ID that associates authentication information with the warehouse configuration.
3. Deploy components to the remote repository
The purpose of using our own remote repository is to deploy the components of our own project in the remote repository as well as those that cannot be directly retrieved from the external repository. This can be used by other team members during development.
In addition to compiling, testing, and packaging projects, Maven can also deploy artifacts generated by projects to remote repositories. First, you need to edit the project’s POM.xml file. Configure the distributionManagement element as follows:
1 <distributionManagement>
2 <repository>
3 <id>releases</id>
4 <name>public</name>
5 <url>http://59.50.95.66:8081/nexus/content/repositories/releases</url>
6 </repository>
7 <snapshotRepository>
8 <id>snapshots</id>
9 <name>Snapshots</name>
10 <url>http://59.50.95.66:8081/nexus/content/repositories/snapshots</url>
11 </snapshotRepository>
12 </distributionManagement>
Copy the codeDistributionManagement contains repository, which represents a repository of release (stable) artifacts, and snapshotRepository child elements, which represent a repository of snapshot (development test) versions. These two elements need to be configured with id, name, and URL. Id is the unique identifier of the remote repository, name is easy to read, and the key URL represents the address of the repository.
Authentication is often required when deploying components to a remote repository. The same method is used to configure authentication.
After the configuration is correct, Maven deploys the artifacts from the project’s build output to the remote repository corresponding to the configuration by running the MVN clean deploy command, or to the repository address of the snapshot version if the project is currently in a snapshot version, or to the repository address of the release version otherwise.
For the difference between a snapshot version and a released version, visit Baidu.
4. Configure a mirror for the remote warehouse
If warehouse X can provide everything stored in warehouse Y, then X can be considered a mirror image of Y. In other words, any artifact that can be obtained from repository Y can be obtained from its mirror image. For example, maven.oschina.net/content/gro… http://repo1.maven.org/maven2/ is the central warehouse of mirror in China, due to the geographical location factor, the image can provide faster than the central warehouse service. Therefore, Maven can be configured to use this image instead of the central repository. Edit settings.xml as follows:
1 <mirrors>
2 <mirror>
3 <id>maven.oschina.net</id>
4 <name>maven mirror in China</name>
5 <url>http://maven.oschina.net/content/groups/public/</url>
6 <mirrorOf>central</mirrorOf>
7 </mirror>
8 </mirrors>
Copy the codeIn this example, the mirrorOf value is central, indicating that this configuration is the mirrorOf the central repository. Any requests to the central repository are forwarded to this mirror. Users can also configure the mirrors of other repositories in the same way. Id indicates the unique identifier of the image, name indicates the name of the image, and URL indicates the address of the image.
A more common use of mirroring is to combine private servers. Since private servers can proxy for any external public repository, including a central repository, using a private server address is equivalent to using all the external repositories needed by Maven users within an organization, which centralizes the configuration into private servers, simplifying the configuration of Maven itself. In this case, any required components can be obtained from the private server, which is the mirror image of all the warehouses. In this case, you can configure a mirror like this:
1 <! -- Configure private server mirroring -->
2 <mirrors>
3 <mirror>
4 <id>nexus</id>
5 <name>internal nexus repository</name>
6 <url>http://183.238.2.182:8081/nexus/content/groups/public/</url>
7 <mirrorOf>*</mirrorOf>
8 </mirror>
9 </mirrors>
Copy the codeIn this case the < mirrorOf > has a value of asterisks, said the configuration is the mirror all Maven repository, any request for remote warehouse will be transferred to http://183.238.2.182:8081/nexus/content/groups/public/. If the mirror repository requires authentication, configure an authentication information with the ID nexus.
Note that because the mirrored repository is completely shielded from the mirrored repository, Maven will still not be able to access the mirrored repository when it is unstable or out of service, and therefore will not be able to download artifacts.
5. Available Maven mirror repository
1 <mirror>
2 <id>repo2</id>
3 <mirrorOf>central</mirrorOf>
4 <name>Human Readable Name for this Mirror.</name>
5 <url>http://repo2.maven.org/maven2/</url>
6 </mirror>
7
8 <mirror>
9 <id>ui</id>
10 <mirrorOf>central</mirrorOf>
11 <name>Human Readable Name for this Mirror.</name>
12 <url>http://uk.maven.org/maven2/</url>
13 </mirror>
14
15
16 <mirror>
17 <id>ibiblio</id>
18 <mirrorOf>central</mirrorOf>
19 <name>Human Readable Name for this Mirror.</name>
20 <url>http://mirrors.ibiblio.org/pub/mirrors/maven2/</url>
21 </mirror>22, 23<mirror>
24 <id>jboss-public-repository-group</id>
25 <mirrorOf>central</mirrorOf>
26 <name>JBoss Public Repository Group</name>
27 <url>http://repository.jboss.org/nexus/content/groups/public</url>
28 </mirror>29 and 30<mirror>
31 <id>JBossJBPM</id>32<mirrorOf>central</mirrorOf>33<name>JBossJBPM Repository</name>34<url>https://repository.jboss.org/nexus/content/repositories/releases/</url>
35 </mirror>
Copy the codeThe above repository has been tested and is accessible.
6. Address of warehouse search service
Sonatype Nexus：repository.sonatype.org/
MVNrepository：mvnrepository.com/
Regarding dependency searches, I personally find these two to be the most useful.
Conclusion: To get you have to pay, to pay you have to learn to insist, if you really feel difficult, then you give up, but you give up don’t complain, the world is really balanced, I think life is like this, everyone is through their own efforts, to determine their own life.
Blogger: AlanLee
Blog: www.cnblogs.com/AlanLee
This post is from bloggarden, welcome to join bloggarden.