pom.xml and settings.xml
pom.xml and setting.xml can be said to be the two most important configuration files in Maven, which determines the core functions of Maven. Although the previous articles mentioned the contents in pom.xml and settings.xml in fragments, they are all briefly mentioned, and the learning and research are not detailed. The purpose of this article is to study these two important configuration files in detail. These two configuration files can lead to a lot of Maven topics.
Maven coordinates
First, let’s talk about why we need to use Maven coordinates.
The Maven world has a very large number of components, that is, some jar, war and other files that are usually used. Before Maven introduces the concept of coordinates for these components, we cannot use any method to uniquely identify all these components. Therefore, if you need to use Spring dependencies, then go to the Spring official website to search; if you need to use log4j dependencies, then go to the Apache official website to search. Because of the different styles of each website, a lot of time is spent on searching and browsing web pages. Without unified norms and rules, work cannot be automated, and repetitive labor should be left to machines.
Maven defines a set of rules: any component in the world can be uniquely identified by Maven coordinates. Maven coordinate elements include groupId, artifactId, version, packaging, and classifier. Now as long as we provide the correct element coordinates, Maven can find the corresponding component. As for where to download, Maven itself has a built-in address of a central warehouse "http://repo1.maven.org/maven2". The central warehouse contains most of the popular open source project components in the world. Mavne will download them when needed. Of course, you can also configure your own central warehouse address and download components in your own central warehouse.
For example, Spring's context:
<dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>4.2.6.RELEASE</version></dependency
Take a look at the elements of the subordinate:
This is roughly the concept of Maven coordinates. Understanding Maven coordinates is a very important step in understanding Maven.
Transitive dependency
What is transitive dependency? Take Spring as an example. When using Spring, you will rely on other open source class libraries. There are two ways to do this:
1. Download a large .zip package that contains all Spring jars, but doing so often introduces many unnecessary dependencies
2. Only download spring-related .zip packages, do not include dependencies. When using them, add other dependencies required according to the error information.
Obviously both approaches are very troublesome, and Maven's transitive dependency mechanism solves this problem well. Open the pom.xml of spring-core-4.1.0.RELEASE, and I intercept a key part:
<dependencies> <dependency> <groupId>commons-codec</groupId> <artifactId>commons-codec</artifactId> <version>1.9</version> <scope>compile</scope> <optional>true</optional> </dependency> <dependency> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> <version>1.1.3</version> <scope>compile</scope> </dependency> ...</dependencies>
For example, project A depends on spring-core, spring-core depends on commons-codec and commons-logging, so commons-codec and commons-logging are transitive dependencies of project A. With the transitive dependency mechanism, when using spring-core, you don’t have to consider what it depends on, and you don’t have to worry about introducing unnecessary dependencies. Maven will parse each direct dependency POM and introduce the necessary indirect dependencies into the current project in the form of transitive dependencies.
With the transitive dependency mechanism, on the one hand, it greatly simplifies and facilitates the dependency declaration. On the other hand, in most cases, we only need to care about what the direct dependencies of the project are and do not need to consider what transitive dependencies will be introduced by these direct dependencies. However, sometimes transitive dependencies will also have some problems. At this time, we need to clear the path from which the transitive dependency was introduced. This is called dependency mediation. There are two main principles of dependency mediation:
1. A->B->C->X(1.0), A->D->X(2.0), at this time, there are two versions of X on the two dependency paths. At this time, the closest path is preferred, so X(2.0) will be parsed and used.
2. The dependency lengths of A->B->Y(1.0), A->C->Y(2.0), Y(1.0) and Y(2.0) are the same. Starting from Maven2.0.9, the first statement follows the priority, that is, the dependency with the highest order is preferred.
Exclude dependencies
Transitive dependencies will implicitly introduce a lot of dependencies to the project, which greatly simplifies the management of project dependencies, but sometimes this feature can also cause problems. For example, there is a situation:
The current project depends on A. A depends on the SNAPSHOT version of another class library for some reason. Then this SNAPSHOT will become a transitive dependency of the current project. Second, the instability of SNAPSHOT will directly affect the current project. At this time, the SNAPSHOT needs to be excluded and a formal release version of the class library is declared in the current project.
It is very simple to exclude dependencies, let’s take a look at the writing method:
<dependency> <groupId>com.alibaba.rocketmq</groupId> <artifactId>rocketmq-client</artifactId> <version>3.2.7</version> <exclusions> <exclusion> <groupId>apache-lang</groupId> <artifactId>commons-lang</artifactId> </exclusion> </exclusions></dependency>
Here I introduced the dependency of rocketmq, but I don’t want to rely on apache-lang in rocketmq, but want to introduce dependencies by myself, so I excluded apache-lang.
It should be noted here that when declaring the exclusion, only groupId and artifactId are needed, and version elements are not needed. This is because only groupId and artifactId are needed to uniquely locate a dependency in the dependency graph. In other words, in the Maven parsed dependencies, it is impossible to have two dependencies with the same groupId and artifactId, but different versions.
settings.xml
settings.xml is the basic configuration of Maven. There are many elements, so let's take a look at it one by one.
1. proxy
proxy means Maven's proxy. Let's take a look at the writing method:
<proxies> <proxy> <id>optional</id> <active>true</active> <protocol>http</protocol> <username>proxyuser</username> <password>proxypass</password> <host>proxy.host.net</host> <port>80</port> <nonProxyHosts>local.net|some.host.com</nonProxyHosts> </proxy></proxies>
proxy is needed because many times your company requires you to access the Internet using a security certified proxy based on security considerations. In this case, you need to configure an HTTP proxy for Maven to allow it to access the external repository normally to download the required resources. Multiple proxy elements can be configured under proxies. If multiple proxy elements are declared, the first proxy activated will take effect by default. Active is true to activate the proxy, protocol represents the proxy protocol used, of course, the most important thing is to specify the correct host name (host) and port (port). If the proxy server needs authentication, configure username and password. The nonProxyHost element indicates which host names do not require a proxy. You can use "|" to separate multiple host names, and also support wildcard "*".
2. Repository
The repository represents Maven's central warehouse, because although the components in the default remote warehouse are very large, there will always be times when they do not meet our needs, and then other central warehouses will be used. Let's take a look at the writing method:
<repository> <id>public</id> <name>local private nexus</name> <url>http://192.168.1.6:8081/nexus/content/groups/public</url> <releases> <enabled>true</enabled> </releases> <snapshots> <enabled>false</enabled> </snapshots></repository>
Multiple repository can be declared. The id must be unique. Pay special attention that the id used by the central repository that Maven comes with is central. If other repository declarations also use this id, the configuration of the central repository will be overwritten. Releases and snapshots are more important. The former means opening the release version download support for the repository, and the latter means closing the snapshot version download support for the repository. In this way, Maven will go to the repository to download the release version of the repository without downloading the snapshot version of the repository.
3. Server
Most remote warehouses can be accessed without authentication, but sometimes they are considered in security factors and need to provide authentication information to access some remote warehouses. For security considerations, authentication information is generally only placed in settings.xml, and server is the authentication element. Take a look at the configuration:
<server> <id>nexus-releases</id> <username>deployment</username> <password>deployment</password></server>
The key here is the id. This id must be exactly the same as the id of the repositiry element that needs to be authenticated. In other words, the formal id links the authentication information and the repository configuration.
4. Mirror
If warehouse X can provide all the content stored in warehouse Y, then warehouse X can be considered as a mirror of warehouse Y. In other words, any component that can be obtained from Y can be obtained from X. For example, "http://maven.net.cn/content/groups/public/" is a central warehouse "http://repo1.maven.org/maven2/" in China. Due to geographical location factors, the mirror is often able to provide faster services than the central warehouse, which is why mirror is used.
Take a look at the configuration of mirror:
<mirror> <id>nexus</id> <name>internal nexus repository</name> <url>http://192.168.1.6:8081/nexus/content/groups/public</url> <mirrorOf>*</mirrorOf></mirror>
In this example, mirrorf is *, indicating that the configuration is a mirror for all central repositories, and any requests for the central repository will be transferred to the mirror. The other three elements id, name, and url are no different from the general warehouse configuration, representing the unique identifier, name and address of the mirror warehouse. Similarly, if the image requires authentication, the repository authentication can also be configured based on the id.
Thank you for reading, I hope it can help you. Thank you for your support for this site!