Internet development, especially in the field of Java, can be said to be everywhere in Maven. Maven's warehouse management, dependency management, inheritance and aggregation features provide a complete set of solutions for project construction. It can be said that if you don’t understand Maven, then a multi-module project is enough to give you a headache, and dependency conflicts will cause you You are at a loss, and you don't even know how the project works... Yes, I have been "hurt" by Maven before. It's so annoying.
(There are super benefits in the article)
Thinking in Maven
Recall that when you are new to a company, after installing the JDK, Maven (MAVEN_HOME, path) will be installed and configured. It is very likely that you need to modify the settings.xml file. For example, you will modify the local warehouse address path. A section of configuration will be copied to your settings.xml (probably some configuration of the private server). Next, you will go to IDEA or Eclipse to configure the Maven plug-in, and then you can start adding tags to manage the jar package in the pom.xml in the project, write code under the directory structure of the Maven specification, and finally you will pass Plug-ins are used to test, package (jar or war), deploy, and run.
The above describes some of our use of Maven, let's think about it:
Q1: Local warehouse? What warehouses does Maven have? What is their relationship?
Maven warehouse
local warehouse path configuration
If you want a jar package, it’s impossible to download it through the Internet every time. It takes a lot of effort, so the local warehouse is equivalent to adding a layer of jar package cache. Check it here first. If you can't find it here, then go to the private server. If you can't find the private server, then go to the central warehouse to find it. After finding the jar, the jar information will be synchronized to the private server and the local warehouse.
The private server is just a server on the company's internal LAN. Think about it, when your project Project-A relies on someone else's Project-B interface, what should you do? When there is no Maven, it is of course to copy Project-B jar to your local lib and import it. Then the Maven method obviously requires others to deploy Project-B to the private server warehouse for you to use. Therefore, the company's internal dedicated jar is stored in the private server! Not only that, the private server also acts as a mirror image of the central warehouse, which is an agent in plain terms!
Central warehouse: This warehouse stores jars on the Internet and is maintained by the Maven team. For example, the address is similar to this: https://repo1.maven.org/XXXX.
If you need more interview materials from major companies, you can also click to enter directly and get it for free! Password: CSDN
Q2: About the use of <dependency>
Dependency management
In fact, this tag reveals the search coordinates of the jar: groupId, artifactId, version.
Generally speaking, we can enter the artifactId on the private server to search, or go to http://search.maven.org/, http://mvnrepository.com/ to search and determine the coordinates.
The version is divided into the development version (Snapshot) and the release version (Release), so why should it be divided?
In actual development, we often encounter such scenarios, such as A service depends on B service, A and B are developed at the same time, B finds a BUG in the development, after modification, upgrade the version from 1.0 to 2.0, then A must also Follow the version upgrade in POM.XML. A few days later, B discovered the problem again, made a modification and released the upgraded version, and then notified A to upgrade... It can be said that this is the unstable version in the development process that caused such a problem.
Maven has already figured out a solution for us, which is to use the Snapshot version. During the development process, the version released by B is marked as the Snapshot version. When A is dependent, the Snapshot version is selected. Then every time B is released, it will be in the private server warehouse. , Form a Snapshot version with a timestamp, and when A is built, it will automatically download the Snapshot version with the latest timestamp of B!
Q3: Since Maven performs dependency management, why does dependency conflict still occur? What is the means to deal with dependency conflicts?
Dependent version?
First of all, for Maven, only one version can be used under the same groupId and the same artifactId!
According to the dependency order in the above figure, the 1.2 version of the jar will be used.
Now, we can think about it. For example, A and B need to be introduced in the project, and A depends on version 1.0 of C, and B depends on version 2.0 of C, then the problem comes, the version of C used will be determined by the order of introducing A and B ? This is obviously unreliable! If the dependency of A is written after the dependency of B, it means that version 1.0 of C was introduced last, and it is very likely that the class (ClassNotFoundException) and method (NoSuchMethodError) could not be found in the runtime (because B uses high Version C)!
There are actually two concepts involved here: transitive dependency and Maven's recent dependency strategy.
Dependency transfer: If A depends on B and B depends on C, then the introduction of A means that both B and C will be introduced.
Maven's recent dependency strategy: If a project depends on multiple versions of the same groupId and artifactId, the version closest to the project in the dependency tree (mvn dependency:tree) will be used. (It can be seen from here that Maven is a little problematic? Can you choose a higher version for dependency? As far as I know, Gradle is a version+ strategy)
Now, we can think about how to deal with dependency conflicts?
Idea 1: We know which version to use, so can it be version locked regardless of how dependent delivery is?
Use <dependencyManagement> [This is mainly used for version consistency of submodules]
Idea 2: In dependency transmission, can we remove what we don’t want to depend on?
Use [In practice, we can directly use plug-ins in IDEA to help us generate]
Idea 3: Since it is the recent dependency strategy, then we directly use the explicit dependency specified version, isn't that the closest to the project?
Use <dependency>
Q4: Introduce the best practice of dependency and find problems in advance!
In the project, we can't avoid the need to add some dependencies. Maybe after adding the dependencies, we find that there are dependency conflicts to be resolved when running. It seems a bit late! Can the problem be discovered in advance?
If we add a new dependency, first form a dependency tree through the mvn dependency:tree command to see if there is a transitive dependency in our newly added dependency, whether there is a conflict between the transitive dependency and the version in the dependency tree, if there are multiple Version conflicts, use the above method to resolve!
Q5: Maven standardized directory structure
There are 2 points to note here:
First: The content under src/main will eventually be packaged into Jar/War, while the content under src/test is the test content and will not be packaged.
Second: The resource files in src/main/resources will be COPY to the target directory, which is a prescribed action in the default life cycle of Maven. (Think about it, hibernate/mybatis mapping XML needs to be placed under resources, but not elsewhere)
Reader benefits
Thank you for seeing here!
I have compiled a lot of 2021 latest Java interview questions (including answers) and Java study notes here, as shown below
The answers to the above interview questions are organized into document notes. As well as interviews also compiled some information on some of the manufacturers & interview Zhenti latest 2021 collection (both documenting a small portion of the screenshot) free for everyone to share, in need can click to enter signal: CSDN! Free to share~
If you like this article, please forward it and like it.
Remember to follow me!
