4. Warehouse

1. What is a warehouse

    The output of any dependency, plugin, or project build in Maven can become a component. This unified location where Maven uniformly stores the shared artifacts of all Maven projects is the repository.

 

2. Warehouse layout

    Any component has its unique coordinates, according to which the unique storage path in the warehouse can be defined. This is how Maven repositories are laid out.

    For example: log4j:log4j:1.2.17 This dependency corresponds to the path \repository\log4j\log4j\1.2.17

    The approximate relationship between its path and coordinates is groupId/artifactId/version/artifactId-version.packaging

 

3. Classification of warehouses

    There are two types of repositories: local repositories and remote repositories.

    When Maven looks for a component according to the coordinates, it first looks at the local warehouse, and if it exists, use it directly; if the component does not exist in the local warehouse, Maven will go to the remote warehouse to find the required component, and download it to the local warehouse for use. If neither the local repository nor the remote repository has the required artifacts, Maven will report an error.

Special remote repository:

    • Central warehouse: It is the remote warehouse that comes with Maven core, which contains most of the open source components.

    • Private server: It is a private warehouse server set up in the local area network, which is used as an agent for all external remote warehouses, and internal projects can also be deployed on private servers for other projects to use.

    • Other public remote repositories: Java.net Maven repository (http://download.java.net/maven/2/) and JBoss Maven repository (http://repository.jboss.org/maven2/) are common

 

 (1) Local warehouse

    The local repository is specified in ~/.m2/settings.xml

    Default: ~/.m2/repository

    Configurable via localRepository, e.g.

 

<settings>
    <localRepository>D:\repository</localRepository>
</settings

    Note: The ~/.m2/settings.xml file does not exist. You need to copy $M2_HOME/conf/setting.xml from the Maven installation directory before editing it. It is not recommended to directly modify the global setting.xml file

 

The way components enter the warehouse:

    • Download from remote repository

    •mvn clean install

 

(2) Remote warehouse

    After Maven is installed, if you do not execute any Maven commands, the local repository directory does not exist. Maven will not create a local repository until the user enters the first Maven command.

 

(3) Central warehouse

    Since the most original local repository is empty, Maven must know at least one available remote repository to download the artifacts when executing Maven commands.

    $M2_HOME/lib/maven-model-builder-3.0.4.jar, then visit maven-model-builder-3.0.4.jar\org\apache\maven\model\pom-4.0.0.xml, you can see The following information:

 

  <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 is the super POM that all Maven projects inherit

 

    id: central Uniquely identifies the central repository; name name: Central Repository; layout: default; snapshots-enabled-false means not to download snapshot version components from the central repository.

 

(4) Private server

    The private server is a special remote warehouse set up in the local area network.

When Maven needs to download a component, it requests it from the private server. If it does not exist, it downloads it from an external remote repository, caches it on the private server, and then serves Maven's download request. In addition, some components that cannot be downloaded from external repositories can also be uploaded locally to the private server.

    The role of private service:

    • Save your own extra network bandwidth;

    • Speed ​​up Maven builds

    • Deploy third-party components, when a component cannot be obtained from any external remote repository, such as an organization's internal private component, Oracle's JDBC driver. After the private server is established, these components can be deployed to this internal warehouse for use by the internal Maven project;

    • Improved stability and enhanced control

    • Reduce the load on the central warehouse

 

4. Configuration of remote warehouse

    The content of the warehouse can be configured in the POM or setting.xml as follows:

<project>
	<repositories>
		<repository>
			<id>jboss</id>
			<name>JBoss Repository</name>
			<url>http://repository.jboss.com/maven2/</url>
			<layout>default</layout>
			<releases>
				<enabled>true</enabled>
			</releases>
			<snapshots>
				<enabled>false</enabled>
			</snapshots>
		</repository>
	</repositories>
</project>

id: Unique identifier. Note that the central warehouse ID is central. If other warehouses declare to use this ID, the configuration of the central warehouse will be overwritten.

layout: indicates that the layout of the warehouse is the default layout of Maven2 and Maven3.

releases: The value of the enabled sub-element is true, indicating that the release version download support of the JBoss repository is enabled.

snapshots: The value of the enabled sub-element is false, which disables the download support of the snapshot version of the JBoss repository.

releases和snapshots:

The updatePolicy sub-element configures the update frequency. The default value is daily, which means that Maven checks once a day. Other values ​​never - never check for updates; always - check for updates every build; interval:X - check for updates every X minutes;

The checksumPolicy sub-element is used to configure Maven's policy for checking checksum files. When the component is deployed to the Maven repository, the checksum file will be verified. If the checksum verification fails, the default is warn, and a warning message will be output; fail, the component fails; ignore, ignore

 

(1) Authentication of remote warehouse

    Authentication information must be configured in setting.xml

 

<settings>
  ...
  <servers>
    <server>
      <id>deploymentRepo</id>
      <username>repouser</username>
      <password>repopwd</password>
    </server>
    <server>
      <id>siteServer</id>
      <privateKey>/path/to/private/key</privateKey>
      <passphrase>optional; leave empty if not used.</passphrase>
    </server>
  </servers>
  ...
</settings>

 

 

(2) Deploy to remote warehouse

    Need to edit pom.xml file

 

<project>
	<distributionManagement>
		<repository>
			<id>proj-release</id>
			<name>Proj Release Repository</name>
			<url>http://192.168.1.100/content/repository/proj-releases</url>
		</repository>
		<snapshotRepository>
			<id>proj-snapshot</id>
			<name>Proj Snapshot Repository</name>
			<url>http://192.168.1.100/content/repository/proj-snapshot</url>
		</snapshotRepository>
	</distributionManagement>
</project>

    distributionManagement contains repository and snapshotRepository sub-elements. The former represents the release version artifact repository and the latter represents the snapshot version artifact repository. Both sub-elements need to be configured with id, name, and url.

When deploying to a remote warehouse, authentication is required. The configuration method is to create a server element in setting.xml, whose id matches the id of the warehouse, and configure the correct authentication information. The authentication configuration methods for downloading components and deploying components are the same.

Deployment command:

mvn clean deploy

 

5. Snapshot version

    Snapshots are mainly used for collaborative development within the organization. If it is a SNAPSHOT version, the component will be time stamped during the process of publishing to the private server, for example: 2.1-20091214.221414-13, other projects that depend on this component can be found in components are checked. Checks once a day by default (updatePolicy is controlled), you can also use the command line -U parameter to force Maven to check for updates

mvn clean install -U

 

6. Mechanism for resolving dependencies from the repository

    The rules for Maven to resolve and use dependency artifacts from repositories are as follows:

    (1) When the dependency scope is system, Maven parses the component directly from the local system;

    (2) After calculating the warehouse path according to the dependent coordinates, try to find the component directly from the local warehouse. If the corresponding component is found, the analysis is successful;

    (3) In the case that there is no corresponding component in the local warehouse, if the dependent version is the displayed release version component, such as 1.2, 2.1-beta-1, etc., then traverse all remote warehouses, and after discovery, download, parse and use;

    (4) If the dependent version is RELEASE or LATEST, read the metadata groupId/artifactId/maven-metadata.xml of all remote warehouses based on the update strategy, merge it with the corresponding metadata of the local warehouse, and calculate the RELEASE or LATEST the real value, and then check the local or remote repository based on this real value, as in steps (2) and (3);

    (5) If the dependent version is SNAPSHOT, read the metadata groupId/artifactId/version/maven-metadata.xml of all remote warehouses based on the update strategy, and merge it with the corresponding metadata of the local warehouse to get the latest snapshot version , then check the local or remote repository for download;

    (6) If the component version obtained by parsing is a snapshot in a timestamp format, such as 1.41-20091104.121451-121, copy the file in the timestamp format to a non-timestamp format, such as SNAPSHOT, and use the component in the non-timestamp format.

 

7. Mirror

The configuration in settings.xml is as follows:

 

<settings>
  </mirrors>
	<mirror>
		<id>maven.net.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>
    mirrorOf: refers to the ID of the mirrored warehouse; the other three elements id, name, and url are the same as general warehouses.

 

 

The more common usage is combined with private server

<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>
    <mirrorOf>*</mirrorOf>: go to http://192.168.1.100/maven2/ for any remote request;

    <mirrorOf>external:*</mirrorOf> : matches all remote repositories except those using localhost and those using file://. That is to match all remote repositories that are not on the local machine;

    <mirrorOf>repo1,repo2</mirrorOf>: Match repo1 and repo2, use commas to separate multiple remote repositories;

    <mirrorOf>*,!repo1</mirrorOf>: Match all remote repositories except repo1, use an exclamation mark to exclude repositories from matching.

 

8. Maven Search Service

(1)Sonatype Nexus

Address: https://repository.sonatype.org/index.html#welcome

Nexus is the most popular open source Maven warehouse management software, a Nexus warehouse instance set up by Sonatype.

 

(2)Jarvana

Address: http://www.jarvana.com/jarvana/

Jarvana provides search based on keyword and class name

 

(3) Central warehouse

Address: http://search.maven.org/#browse

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=327034448&siteId=291194637