What is a Maven repository:In the maven world, any dependency, plug-in, or project build output can be called components. For example, a dependency log4j-1.2.15.jar is a component and a plug-in maven-compiler-plugin-2.0.2.jar is a component. Each component has a set of unique coordinates. Thanks to the coordinate mechanism, any Maven project uses any component in the same way. On this basis, Maven can store all the components shared by Maven projects in a unified manner at a specific location, which is the repository. In actual Maven projects, other dependent files are no longer stored. They only need to declare the coordinates of these dependencies, as needed (for example, add dependencies to classpath when compiling a Project). MAVEN automatically finds the components in the repository based on the coordinates and uses them. To achieve reuse, components generated after the project is built can also be installed or deployed in the repository for other projects.
Repository layout:Each component has its unique coordinates. Based on the coordinates, you can define its unique storage path in the repository. This is the maven repository layout method. For example, log4j: log4j: 1.2.15 this dependency, its corresponding warehouse path is log4j/log4j/1.2.15/log4j-1.2.15.jar, careful readers can find, the approximate correspondence between the path and coordinates is groupid/artifactid/version/artifactid-version (-classifier ). packaging.
Warehouse category:For Maven, there are only two types of repositories: Local repositories and remote repositories. When Maven looks for a component based on the coordinates, it first looks at the local repository. If this component exists in the local repository, it is used directly. If this component does not exist in the local repository, or you need to check whether any updated component version exists. MAVEN will go to the remote repository to find the required component and download it to the local repository for use. If neither the local repository nor remote repository has any required components, Maven reports an error. There are several types of special remote warehouses. The central repository is a remote repository built on the maven core. It contains a vast majority of open source components. In the default configuration, when the local repository does not have the components required by Maven, it will try to download them from the central repository. Private server is another special remote warehouse. To save bandwidth and time, a private warehouse server should be set up in the LAN to proxy all external remote warehouse servers. Internal projects can also be deployed on private servers for other projects. In addition to the central repository and private server, there are many other public remote repositories, common ones include the java.net Maven Library and the JBoss Maven library.
Local Repository:By default, on Windows or Linux, each user has a repository directory named. m2/Repository/under his/her own user directory. Note: in Linux, files or directories starting with a dot (.) are hidden by default. You can use the LS-a command to display hidden files or directories. Sometimes, for some reason (for example, the disk C is not enough space), the user wants to customize the local repository directory address. In this case, you can edit the file ~ /. M2/settings. XML, set the value of the localrepository element to the desired repository address. For example: <Settings> <localrepository> D: \ Java \ repository \ </localrepository> </Settings>, the local repository address of the user is set to D: \ Java \ repository.
Central Repository:The central repository is the default remote repository used by maven. The Maven Installation File comes with the configuration of the central repository. Readers can use the decompression tool to open the jar file $ m2_home/lib/maven-model-builder-3.0.jar and then access the path ORG/Apache/Maven/model/pom-4.0.0.xml. You can see:
<repositories> <repository> <id>central</id> <name>Central Repository</name> <url>http://repo.maven.apache.org/maven2</url> <layout>default</layout> <snapshots> <enabled>false</enabled> </snapshots> </repository> </repositories>
The file containing this configuration section is the Super pom that all Maven projects will inherit. The Inheritance and super pom will be detailed later. The ID center used in this configuration uniquely identifies the central repository. Its name is Maven repository switchborad, which uses the default repository layout. Note that the value of the snapshots element enabled is false, indicating that the snapshot version component is not downloaded from the central repository. The central repository contains the vast majority of popular open source Java software in the world, as well as source code, author information, SCM, information, license information, and so on. Generally, all the dependent components required by a simple Maven can be downloaded from the central repository.
Private Server:Private Server is a special remote warehouse. It is a registry service built in the LAN. Private server proxy is a remote warehouse on the Wide Area Network for Maven users in the LAN. When Maven needs to download the component, it requests from the private server. If the component does not exist on the private server, it downloads the component from the external remote repository and caches it on the private server, provide services for Maven download requests. In addition, some components that cannot be downloaded from external warehouses can also be uploaded locally to private servers for your use (this is very important, many internal projects of the company need to communicate with each other, but requires that the company cannot access these resources ). The benefits of private servers are similar to the cache mechanism used on computers. The following are detailed:
- Save your own Internet bandwidth: a large amount of repeated requests to external warehouses will consume a lot of bandwidth. After the private server proxy external warehouse is used, external duplicate component downloads will be eliminated, this reduces the Internet bandwidth pressure.
- Accelerating Maven building: It is very time-consuming to constantly connect to external warehouses. using private servers can solve this problem. When Maven only needs to check the data of private servers in the LAN, the building speed can be greatly improved.
- Deploy third-party components: after creating a private server, you can deploy the internal components to this internal repository for internal Maven projects.
- Improved stability and enhanced control: Maven components are highly dependent on remote warehouses. Therefore, when the Internet is unstable, Maven build may be unstable or even unable to be built. Maven can be used normally even if there is no Internet link for private servers. In addition, some private server software (such as nexus) also provides many additional features, such as permission management, realcompute/snapshot partitioning, and so on. administrators can perform more advanced control over the repository.
- Reduce central warehouse Load
Remote repository Configuration:In many cases, the default remote repository cannot meet the needs of the project. The components required by the project may exist in another remote repository, such as the JBoss Maven repository. In this case, you can configure the repository in POM (you can configure a remote repository in settings. XML, which has different scopes ):
<repositories> <repository> <id>jboss</id> <name>JBoss Repository</name> <url>http://repository.jboss.com/maven2</url> <releases> <enabled>true</enabled> </releases> <snapshots> <enabled>false</enabled> </snapshots> <layout>default</layout> </repository> <repositories>
The repositories element can contain one or more remote repositories declared using the repository sub-element. The ID used by any repository must be unique. Because the central repository ID used by Maven is central, if other repository declarations use this ID, the configuration of the central repository will be overwritten. The URL value in this configuration points to the repository address. Generally, the address is based on the HTTP protocol. MAVEN users can open the repository address browsing component in the browser. The release and snapshots elements in the configuration are used to control Maven's download of the release and snapshot components. For the following enabled element, if enabled is true, the corresponding release or snapshots version can be downloaded, and vice versa. In addition to enabled, they also contain two sub-elements, updatepolicy and checksumpolicy:
<snapshots> <enabled>true</enabled> <updatePolicy>daily</updatePolicy> <checksumPolicy>ignore</checksumPolicy></snapshots>
The updatepolicy element is used to configure how often Maven checks for updates from a remote repository. The default value is daily, which indicates that Maven checks updates every day. Other available values include: Never-Never check for updates; always-check for updates each build; interval: X-check for updates every X minutes (X is any integer ). The element checksumpolicy is used to configure the maven check and file policy. When the component is deployed to the maven repository, the corresponding check and file will be deployed at the same time. Checksumpolicy is used to determine the policy adopted when verification and verification fail to be performed when a component is downloaded: When the checksumpolicy value is the default warn, MAVEN will output a warning when executing the component, other available values include: fail-MAVEN will fail the component when it encounters a check and error; ignore-will make Maven completely ignore the checksum error.
Remote repository authentication:Most remote warehouses do not require authentication. Sometimes, for security reasons, for example, a remote repository server built by a company, we need to provide authentication information for access. In this case, you need to configure authentication information to allow Maven to access the repository content. The configuration authentication information is different from the configuration warehouse information. The authentication information can only be configured in settings. in XML files, this is because Pom is often submitted to the code repository for access by all members, and setting. XML is generally stored only on the local machine. Therefore, it is safer to configure authentication information in settings. xml. Assume that you need a repository with ID my-proj to configure authentication information. to edit the settings. xml file, see the code below:
<settings>... <servers> <server> <id>my-proj</id> <username>repo-user</username> <password>repo-pwd</password> <server> <servers> ...</settings>
The server element ID in settings. xml must be exactly the same as the ID of the Repository element to be authenticated in pom. In other words, this ID associates the authentication information with the repository configuration.
Deploy to a remote Repository:A major role of private servers is to deploy third-party components, including components generated within the Organization and components that cannot be directly obtained from external warehouses for use by other teams. First, edit the POM and XML files of the project. To configure the distributionmanagement element, see the code below:
<project>... <distributionManagement> <repository> <id>proj-release</id> <name>Proj Release Repository</name> <url>http://192.168.1.100/content/repositories/proj-releases</url> </repository> <snapshotRepository> <id>proj-snapshots</id> <name>Proj Snapshot Repository</name> <url>http://192.168.1.100/content/repositories/proj-snapshots</url> </snapshotRepository> <distributionManagement>...<project>
Distributionmanagement contains the repository and snapshotrepository sub-elements. The former indicates the repository of the released component, and the latter indicates the repository of the snapshot version. The ID, name, and URL must be configured under these two elements. ID is the unique identifier of the remote repository, so that it is easy to read. The key URL represents the address of the repository. When deploying components to a remote warehouse, authentication is often required. In short, it is necessary to create a server element in settings and XML, whose ID matches the repository ID, and configure the correct authentication information. Whether you download components from a remote repository or deploy components to a remote repository, the configuration method is the same when authentication is required. After the configuration is correct, run
MVN clean deployMaven will deploy the components built and output by the project to the remote repository corresponding to the configuration. If the current version of the project is the snapshot version, deploy it to the snapshot version repository address, otherwise, it will be deployed to the repository address.
Snapshot version:The Snapshot version has two main functions. 1. Used to differentiate between stable and unstable components: the released version is stable, and the snapshot version is unstable. 2. It is used to avoid the problem that version numbers are constantly upgraded due to version upgrades, resulting in a flood of version numbers. (This is the meaning of the word "snapshot ). The following is a detailed explanation. For example, if you want to set the version of module A to 2.1-Snapshot and then release it to the private server, MAVEN will automatically stamp the component during the release process. For example, 2.1-20091214.221414-13 indicates the first snapshot at, January 1, 13th. With this timestamp, Maven can find the latest 2.1-Snapshot version of this component in the repository at any time. In this case, there is a dependency of Module B on module A's 2.1-Snapshot version. When building module B, MAVEN will automatically check the latest 2.1-Snapshot component of module A from the repository, download the SDK when an update is found. By default, Maven checks for updates once a day (controlled by the updatepolicy configured by the repository). You can also use the command line-u parameter to force Maven to check for updates, as shown in
MVN clean install-u. When the project needs to be released after a complete test, you should change the snapshot version to the released version. For example, changing 2.1-snapshot to 2.1 means that the version is stable and only corresponds to the unique component. In contrast, 2.1-Snapshot often corresponds to a large number of components with different timestamps, which also determines their instability. The Snapshot version should only be used by projects or modules within the Organization, because the Organization has full understanding and control over the dependencies of these snapshot versions. The project should not depend on the snapshot version outside any organization. Due to the instability of the snapshot version, such dependency may cause potential risks. That is to say, even if the project is successfully built today, because the external snapshot version depends on the actual corresponding component may change at any time, the project construction may fail due to these external uncontrolled factors.
Image:If warehouse X can provide all the content stored in warehouse y, it can be considered that X is an image of Y. In other words, any component that can be obtained from Warehouse y can be obtained from its image. For example, callback. Therefore, you can configure Maven to use this image to replace the central repository. Edit settings. xml:
<settings>... <mirrors> <mirror> <id>maven.cn.cn</id> <name>one of the central mirrors in China</name> <url>http://maven.net.cn/content/groups/public</url> <mirrorOf>central</mirrorOf> </mirror> <mirrors>...<settings>
In this example, the value of <mirrof> is "Central", indicating that the image is configured as the central repository. Any request to the central repository is forwarded to the image, you can also configure images of other repositories in the same way. A more common use of images is to combine private servers. Because private servers can represent any external public warehouse (including the central warehouse), for Maven users in the Organization, using a private server address is equivalent to using all the required external warehouses, this allows you to centralize configurations to private servers to simplify Maven configurations. In this case, any required component can be obtained from the private server, which is the image of all warehouses. You can configure an image as follows:
<settings>... <mirrors> <mirror> <id>internal-repository</id> <name>Internal Repository Manager</name> <url>http://192.168.1.100/maven2</url> <mirrorOf>*</mirrorOf> </mirror> <mirrors>...<settings>
In this example, the value of <mirrof> is an asterisk, indicating that the configuration is the image of all Maven repositories. Any requests to remote repositories are forwarded to http: // 192.168.1.100/maven2 /. If the image repository requires authentication, configure a <Server> with the ID of internal-repository. Maven also supports more advanced image Configuration:
- <Mirrorof> * </mirrorof>: matches all remote repositories.
- <Mirrorof> External: * </mirrof>: All remote repositories are matched, except for localhost and file: // protocol. That is, all remote repositories that are not on the local machine are matched.
- <Mirrorof> repo1, repo2 </mirrorof>: Match repository repo1 and repo2 and separate Multiple Remote warehouses with commas (,).
- <Mirrorof> *,! Repo1 </mirrof>: matches all remote warehouses, except repo1. Uses exclamation points to exclude warehouses from matching.
It should be noted that, because the image repository is completely shielded from the image repository, MAVEN will still be unable to access the image repository when the image repository is unstable or the service is stopped, therefore, the component cannot be downloaded.
Maven Study Notes (5): Repository
