Send you the following java learning materials. There is a way to get them at the end of the text
Maven can be seen everywhere in the current project. During the interview, you are often asked some questions about Maven in the project, but usually there are no problems with Maven project. Maybe you don’t pay much attention to it. The following seven questions are generally said and mastered, which can at least prove that your proficiency in Maven is OK.
Maven’s warehouse management, dependency management, inheritance, aggregation and other features provide a complete set of solutions for the construction of the project. If you don’t understand maven, a multi module project is enough to give you a headache. Dependency conflict will make you at a loss and even don’t know how the project works
OK, bloggers have been “hurt” by maven, so we want to:Take care of Maven!
Recall that when you come to a new company, Maven will be installed and configured after installing JDK. It is very likely that you need to modify settings XML file. For example, you will modify the address path of the local warehouse. For example, you are likely to copy a section of configuration to your settings XML (probably some configuration of private server). Next, you will configure Maven plug-in in idea or eclipse, and then you can use POM. Com in the project XML starts to add tags to manage jar packages and write code under the directory structure of Maven specification. Finally, you will test, package (jar or war), deploy and run through plug-ins.
The above describes some ways to use Maven. Let’s think about it:
1. Local warehouse? What warehouses does Maven have? What is their relationship?
Local warehouse path configuration:
If you want a jar package, you can’t go online to download it every time. It’s so hard, so the local warehouse is equivalent to adding a layer of jar package cache. Check here first. If you can’t find it here, go to the private server. If you can’t find it, go to the central warehouse. After finding the jar, you will synchronize the jar information to the private server and the local warehouse.
Private service, it’s just a server in the company’s internal LAN. Think about it. When your project-a depends on someone else’s project-b interface, what should you do? When there is no maven, of course, copy project-b jar is imported into your local lib. Obviously, Maven’s method requires others to deploy project-b to the private server warehouse for your use.Therefore, the company’s internal special jars are stored in the private server! Not only that, the private server also acts as a mirror image of the central warehouse. In short, it is an agent!
Central warehouse: the warehouse stores jars on the Internet and is maintained by Maven team. The address is:http://repo1.maven.org/maven2/。
In fact, this tag reveals the lookup coordinates of jar:groupId、artifactId、version。
Version is divided into development version (snapshot) and release version (release), so why divide it?
In the actual development, we often encounter such scenarios. For example, service a depends on service B. A and B develop 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 in POM Version upgrade in XML. After a few days, B found the problem again, modified it and released the upgraded version, and then notified a to upgrade It can be said that this problem is caused by the unstable version in the development process.
Maven has 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, and a selects the snapshot version when relying on it. Then each time B releases it, a snapshot version with a timestamp will be formed in the private server warehouse, and a will automatically download the snapshot version with the latest timestamp of B when building it!
3. Since Maven has implemented dependency management, why does dependency conflict still occur? What are the means to deal with dependency conflicts?
First of all,For maven, only one version can be used under the same groupid and the same artifact ID！
According to the dependency order in the figure above, version 1.2 jar will be used.
Now, we can think about it. For example, if a and B need to be introduced into 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 used by C will depend on 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 the last introduced version of C is version 1.0, and classes are likely to appear in the run-time stage（ClassNotFoundException）. method（NoSuchMethodError）Error not found (because B uses a higher version of C)!
There are actually two concepts involved here: dependency transitive and Maven’s recent dependency strategy.
Dependency passing: if a depends on B and B depends on C, introducing a means that both B and C will be introduced.
Maven’s nearest 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 the fact that there is a problem with relying on a smaller version of grave + (can we choose a higher version of grave or not)
Now, can we think about how to deal with dependency conflicts?
Idea 1: we know which version to use, so can we lock the version no matter how dependent the delivery is?
<dependencyManagement>This is mainly used in the version consistency of sub modules
Idea 2: in dependency delivery, can we remove what we don’t want to rely on?
<exclusions>In practice, we can directly use plug-ins in idea to help us generate
Idea 3: since it is the most recent dependency strategy, we can directly use the explicit dependency specified version. Isn’t that the one closest to the project?
4. Introduce dependent best practices and find problems in advance!
In the project, we can’t avoid adding some dependencies. Maybe after adding dependencies, the runtime finds that there are dependency conflicts to solve. It seems a little late! So can we find the problem 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 transfer dependency and whether there is a conflict between the transfer dependency and the version in the dependency tree. If there are multiple version conflicts, use the above method to solve them!
5. Maven normalized directory structure
Here are two points to note:
1. The content under Src / main will eventually be packaged into jar / war, while the test content under Src / test will not be packaged.
2. The resource file in Src / main / resources will copy to the target directory, which is a specified action in Maven’s default life cycle. (think about it. The mapping XML of Hibernate / mybatis needs to be placed under resources, but not elsewhere)
6. Maven’s life cycle
Maven life cycle:
We just need to pay attention to one thing:When the following command is executed, the previous command is automatically executed.
In fact, these are the most commonly used:
1. Clean: if there is a problem, clean it up more!
2. Package: when the jar or war package is generated, clean + compile will be performed automatically
3. Install: upload the local project jar to the local warehouse
4. Deploy: upload to private server
7. About scope dependency scope
Since Maven’s life cycle involves compiling, testing and running these processes, it is obvious that some dependencies are only used for testing, such asjunit； Some dependency compilation can’t be used and can only be used when running, such asMySQL driver packageNot at compile time（The JDBC interface is used at compile time）, but used at runtime; There are also some dependencies that need to be used at compile time, but do not need to be provided at run time, because some containers have been provided, such asservlet-apiIt has been provided in Tomcat. All we need is to provide it at compile time.
1. Compile: the default scope, which is valid during the running period and needs to be entered into the package.
2. Provided: the compilation period is valid, and the runtime does not need to be provided and will not be entered into the package.
3. Runtime: compilation is not required. It is valid during the runtime and needs to be imported into the package. (separation of interface and Implementation)
4. Test: it needs to be tested and will not be entered into the package.
5. System: jars imported from non local warehouses and existing in a path of the system. (generally not used)