Maven coordinates

What are maven coordinates

The word coordinate most familiar to people is the horizontal and vertical coordinates of x and y axes learned in reading. A unique point in a plane is determined by x and y, and x and y are coordinates. In three dimensions, x, y, and z determine a unique point, and x, y, and z are coordinates. In Maven, attributes such as groupId, artifactId, Version, and Packaging determine a unique project module. These attributes are the coordinates of maven projects.

Maven coordinate details

As for groupId, artifactId, Version and Packaging, I have already mentioned them according to my own understanding in the last article. However, after learning this book, I found some deviations in some strategies, so I still need to supplement and correct them. For groupId, I said it was the group to which the project belonged, which might be the company’s website. At that time, MY understanding was actually the company’s website. But reading this chapter, it turns out that groupId is actually the project url for open source projects after they are released, not the company url. It’s just that on previous projects I’ve worked with, a lot of people just wrote the company’s website. This could be because the writer doesn’t know much about the Maven specification, or because the company doesn’t have many projects, so it doesn’t really matter. According to the book, maven’s specifications should not include the company’s website. As for artifactId, what I understood before was the name of the project, and I think it’s still the name of the project. However, the project name should be more specifically understood as the name of the module in the project, a module is actually a separate sub-project. As for version and Packaging, it is easy to understand, which is the same as before, but I have learned a new attribute classifier, which is not commonly used in my opinion. This attribute defines some affiliated components of maven project, which is determined by maven plug-in, and cannot directly define values like the previous attributes. I’m not using this property very often right now, so I’m just looking at it.

Maven rely on

Depend on the configuration

Maven is an excellent dependency management tool, which is also the most important feature of Maven in my opinion. Usually, a complete dependency configuration of Maven looks like this (the following example is just for demonstration, and it is not really possible to exclude web from webMVC) :

<dependency> <groupId>org.springframework</groupId> <artifactId>spring-webmvc</artifactId> <version>4.0.9.RELEASE</version> <scope>test</scope> <type>jar</type> <optional>true</optional> < Exclusions > <exclusion> < the groupId > org. Springframework < / groupId > < artifactId > spring - web < / artifactId > < version > 4.0.9. RELEASE < / version > </exclusion> </exclusions> </dependency>Copy the code

The first three properties in the above configuration are the most commonly used Maven coordinates, and the scope is the effective scope. For example, in the test example, it means only valid during the test phase, that is, when the test method of the test class is running. The default value of scope is compile, which indicates that it is valid for compilation, test, and run phases. In addition to test and compile, there are also runtime, system, etc., I do not use them very much at present, so I will skip for the moment. Type refers to the dependency type, the default is JAR, can be understood as jar package, type can be JAR, WAR, POM, etc. Optional means optional, true means selected, false means not selected, and this property is not used very much. Exclusions and exclusion are exclusions, such as the need to bring in the SPRing-WebMVC JAR package. Spring-webmvc depends on the Spring-Web JAR package. That is to say, when using Maven to display the imported JAR package, Maven also imports the Spring-Web JAR package. If we don’t need Spring-Web, we can configure the spring-Web coordinate exclusion in this place, and then we won’t import the dependency package again.

Depend on the transfer

As in the example above, we will import the JAR package of Spring-WebMVC. Spring-webmvc depends on spring-Web, so we will import the JAR package of Spring-Web in our project. If the scope of spring-Web configured in spring-webMVC is compile, then the dependency scope of spring-Web imported in our project is also compile. But the conclusion above assumes that our project relies on spring-WebMVC in the same scope as the spring-WebMVC relies on Spring-Web. However, when the two dependency scopes are inconsistent, you need to understand the concepts of first and second direct dependencies. In the example above, our project team spring-WebMVC is the first direct dependency, and our project team spring-Web is the second direct dependency. So it’s important to note that sometimes if you have a second direct dependent package that doesn’t work, you can think about it in this way. Another problem is that jars configured with optional dependencies will not be delivered and must be imported manually if necessary.

Rely on mediation

Maven is able to import exactly the dependencies we need according to the configuration because our configuration, known as coordinates, ensures that the dependencies are unique, and if not unique, then we need to make a choice. This involves dependency mediation, or dependency selection. The reason why this is not unique is usually because of dependency passing. For example, I imported two JAR packages A.jar and B. Jar in one project, and both A.jar and B. Jar depend on C. Jar, but the versions of these two C.jar are different. At this time, our project needs to choose which C.jar to use, which is called dependency mediation. So first of all, choose according to the shortest path principle. In connection with the above knowledge, it can be understood as a matter of direct dependence. For example, in the case of A, B, and C, the paths of c. jar are the same length because they are both second direct dependencies. If a.jar depends on c-1. jar, b.jar depends on D.jar, and D.jar depends on C-2. Jar, then C-1 is the second direct dependency, c-2 is the third direct dependency, that is, the path of C-1 is shorter, then C-1 will be chosen instead of C-2. Above, of course, the assumption b.jar surprised relies on jeter ar, so if that is the beginning b.jar is directly dependent on the C – 2. Jar, then the path of the two is the same, it involves the principle of the first statement, that is to say in pom. XML in A and B who before, and who will be selected, It should be noted that this principle comes after maven2.0.9.

Depend on the optimization

MVN Dependency: List MVN Dependency: List MVN Dependency: List MVN Dependency: List MVN Dependency: List MVN Dependency: List MVN Dependency: List Then you can see what level of dependency each dependency is, which dependency it is based on, and then you can do some optimization.