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

This article focuses on "introduction of Maven plug-ins and life cycle". Interested friends may wish to have a look at it. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "the introduction of Maven plug-ins and life cycle".

Maven: is a project management and integration tool (similar to pi in python but more powerful). Maven provides developers with a complete build lifecycle framework. It takes little time for the development team to automate the basic build configuration of the project because Maven uses a standard directory structure and a default build life cycle. Keep in mind here that the convention is greater than the configuration. In short:

The main purpose of Maven is to provide developers with

A comprehensive engineering model that is reusable, maintainable and easier to understand

Plug-ins or tools that interact with this model

Maven's features of warehouse management, dependency management, inheritance and aggregation provide a complete set of solutions for the construction of the project.

The build life cycle of maven is just an abstract specification process. The specific implementation of each phase of the cycle is implemented in the plug-in.

Maven declaration period default definition:

To run any phase, it starts from the first phase of its life cycle and executes sequentially to the specified phase.

Maven plug-in

The plug-in plugin is a component that binds to the lifecycle and undertakes the actual function. When mvn runs, automatically associate plug-ins to run. It can be simply understood that a plug-in is a package with detailed .class files and specific operation functions in .class files.

Some of the ways we use Maven are described above, and here are some thoughts:

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?

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

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?

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

Src/main/java-the .java file that holds the project

Src/main/resources-stores project resource files. For example, spring,hibernate configuration file

Src/test/java-stores all test .java files, such as JUnit test classes

Src/test/resources trial resource file

Target-the output location of a project, and put the compiled things into this location.

Pom.xml-a construction plan for the whole project

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, about 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. Servlet-api

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

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

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

At this point, I believe you have a deeper understanding of the "introduction of Maven plug-ins and lifecycle". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.