Shulou(Shulou.com)06/01 Report--

This article introduces the relevant knowledge of "what are the problems related to Maven". In the operation of actual cases, many people will encounter such a dilemma. Next, let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

1. Local warehouse? What kind of warehouses does Maven have? What's the relationship between them?

Maven Warehouse:

Local warehouse path configuration:

If you want a jar package, you can't download it online every time. It takes a lot of effort, so the local warehouse is equivalent to adding a layer of jar package cache. Check here first. If you can't find it here, then go to the private server, and if you can't find it, go to the central warehouse to find the jar. After finding the jar, you will synchronize the jar information to the private server and the local warehouse.

Private server is just a server in the company's internal local area network. Think about it. When your project Project-A relies on other people's Project-B interface, what should you do? When there is no Maven, of course, copy Project-B jar is introduced into your local lib, so the Maven approach obviously requires someone else to put Project-B deploy into the private server warehouse for you to use. Therefore, the private server stored the company's internal dedicated jar! Not only that, the private server also acts as a mirror image of the central warehouse, which, to put it bluntly, is an agent!

Central warehouse: this warehouse stores jar on the Internet and is maintained by the Maven team at http://repo1.maven.org/maven2/.

2. About the use of

Dependency Management:

In fact, this tag reveals the search coordinates of jar: groupId, artifactId, version.

Generally speaking, we can enter artifactId on the private server to search, or search on http://search.maven.org/ or http://mvnrepository.com/ to determine the coordinates.

Version is divided into development version (Snapshot) and release version (Release), so why divide it?

In the actual development, we often encounter such scenarios, such as A service depends on B service, An and B develop at the same time, B finds BUG in the development, and after modification, the version is upgraded from 1.0 to 2.0, then A must also upgrade the version in POM.XML. After a few days, B found the problem again, modified the upgrade version and released it, and then informed A to upgrade. It can be said that this is caused by version instability in the development process.

Maven, has come up with a solution for us, that is, to use the Snapshot version, the version released by B is marked as the Snapshot version in the development process, and the Snapshot version is selected when An is dependent, then every time B is released, a timestamped Snapshot version will be formed in the private server repository, while A will automatically download the latest timestamped Snapshot version of B when it is built!

3. Since Maven has implemented dependency management, why do dependency conflicts still occur? What is the means to deal with dependency conflicts?

Which version do you rely on?

First of all, for Maven, you can only use one version under the same groupId and the same artifactId!

Based on the dependency order of the figure above, version 1.2 of jar will be used.

Now, we can think about it, for example, An and B need to be introduced into the project, and A depends on the 1.0 version of Cpene B and 2.0 version of C, so the problem is that the version C will use depends on the order in which An and B are introduced. This is obviously unreliable! If A's dependency is written after B's dependency, it will mean that the last version of C is introduced, and there are likely to be errors that cannot be found by classes (ClassNotFoundException) and methods (NoSuchMethodError) at run time (because B uses a higher version of C)!

There are actually two concepts involved here: dependency delivery (transitive) and Maven's recent dependency strategy.

Dependency transfer: if A relies on BBME B and C, then the introduction of A means that both B and C will be introduced.

Maven's recent dependency strategy: if a project relies on multiple versions of the same groupId and artifactId, the version closest to the project will be used in the dependency tree (mvn dependency:tree). (you can see from here whether there is something wrong with Maven? Can you choose a higher version to rely on? It is understood that Gradle is the version+ strategy)

Now, can we think about how to deal with dependency conflicts?

Idea 1: we know which version to use, so can we do version locking no matter how much we rely on delivery?

Use [this is mainly used in version consistency of sub-modules]

Idea 2: in dependency transmission, can we get rid of what we don't want to rely on?

Use [in practice we can directly use plug-ins in IDEA to help us generate]

Idea 3: since it's the recent dependency strategy, let's just use the explicit dependency specified version, isn't that the closest thing to the project?

Use

4. Introduce best practices of dependency and find problems in advance!

In the project, we can not avoid the need to add some dependencies, perhaps after adding dependencies to the runtime to find that there is a dependency conflict to resolve, it seems a little late! So can you find the problem in advance?

If we add a new dependency, first use the mvn dependency:tree command to form a dependency tree to see if our newly added dependency, whether there is a transitive dependency, whether there is a conflict between the transitive dependency and the version in the dependency tree, and if there is a conflict between multiple versions, use the above method to solve it!

5. Maven normalized directory structure

There are two points to note here:

First: the content under src/main will eventually be packaged into Jar/War, while the content under src/test will be tested and will not be packaged.

Second: the resource files in src/main/resources will be COPY to the target directory, which is a specified action in the default life cycle of Maven. (come to think of it, hibernate/mybatis 's mapping XML needs to be placed under resources, not anywhere else.)

6. The life cycle of Maven

Maven Lifecycle:

We only need to pay attention to one thing: when the following command is executed, the previous command is executed automatically.

In fact, these are the most commonly used ones:

Clean: if there's a problem, clean it up!

Package: when packed into a Jar or War package, clean+compile will be performed automatically.

Install: upload the local project Jar to the local warehouse

Deploy: upload to private server

7. On the scope of scope dependency

Since there are compiling, testing and running processes in the life cycle of Maven, it is obvious that some dependencies are only used for testing. For example, some junit; dependencies are not needed for compilation and can only be used at run time. For example, the driver package of mysql is not used at compile time (JDBC interface is used at compile time), but is used at run time. There are also some dependencies, which are used at compile time, but not provided at run time, because some containers are already provided, such as servlet-api is provided in tomcat, and all we need is to provide at compile time.

To sum up:

Compile: the default scope, which is valid during runtime and needs to be included in the package.

Provided: the compile time is valid, the runtime does not need to be provided, and it will not be included in the package.

Runtime: compilation is not required, valid at run time, and needs to be imported into the package. (interface and implementation are separated)

Test: the test is required and will not be included in the package.

System: jar that is introduced by a non-local warehouse and exists in a path of the system. (generally not used)

This is the end of the content of "what are the problems related to Maven"? thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.