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

This article focuses on "how to quickly grasp the core concepts of Maven", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Now let the editor take you to learn "how to quickly master the core concepts of Maven"!

Coordinate

The concept of coordinates

A number or a set of numbers that can determine the position of a point in space, called the coordinates of the point. It is usually expressed by the distance from this point to several fixed lines that intersect vertically. These lines are called axes. The number of axes is 2 in the plane (xrem y) and 3 in the space (xperiary y z).

In fact, it can identify the only point in the plane or space.

Coordinates in Maven

One of the core functions of Maven is to manage project dependencies and introduce various jar packages we need. In order to automatically parse any Java component, Maven must uniquely identify these Jar packages or other resources, which is the basis for managing project dependencies, that is, coordinates. Projects developed by ourselves, including those developed by ourselves, are also uniquely identified by coordinates so that dependent references can be made in other projects.

Case

Dependency time: for example, we rely on junit's jar package below.

Junit junit 3.8.1 test

Our project defined in the project will be packed as a jar or war package.

4.0.0 com.tian maven-demo 1.0-SNAPSHOT jar

The final typed form of jar or war:

Artifactid-version.jar artifactid-version.war

The packaging tag defaults to jar, so usually when we don't specify whether to package jar or war, we end up with a jar package.

Composition of Maven coordinates

"groupId" organization identity (package name). Defines the actual project to which the current Maven project belongs. First of all, there is not necessarily an one-to-one relationship between Maven projects and actual projects. For example, the actual project of SpringFrameWork, there will be many corresponding Maven projects, such as spring-core,spring-context and so on. This is due to the concept of modules in Maven, so an actual project is often divided into many modules. Second, groupId should not correspond to the organization or company to which the project belongs. The reason is simple: there will be many actual projects under an organization. If groupId is defined only at the organizational level, and as we will see later, artifactId can only define Maven projects (modules), then the actual project level will be difficult to define. Finally, the expression of groupId is similar to that of the Java package name, usually one-to-one reverse to the domain name. In the above example, groupId is junit, which makes it feel special, because there is only one junit in the world, and it doesn't have many branches.

"artifactId" project name. This element defines a Maven project (module) in the current actual project, and it is recommended to prefix the artifactId with the actual project name. For example, the junit,junit in the above example is the actual project name, which is convenient and intuitive. By default, the artifacts generated by maven will use artifactId as the file header, such as junit-3.8.1.jar, and use the actual project name as a prefix to easily find the artifacts of a project from the local warehouse.

The current version of the "version" project or we rely on the version of jar. This element defines the version of the component to use. For example, in the above example, the version of junit is 3.8.1, or you can change it to 4.0 to indicate that you use version 4.0 of junit.

The most common packaging methods for "packaging" projects are jar and war, and the default is jar. Define how Maven projects are packaged and what packages of artifacts are used. First of all, the packaging usually corresponds to the file extension of the generated artifact. If there is no packaging in the above example, it defaults to the jar package, and the final file name is junit-3.8.1.jar. It can also be packed into war and so on.

The element "classifier" is used to help define some attachments to the build output. The accessory component corresponds to the main component, for example, the main component in the above example is junit-3.8.1.jar, and the project may also generate something like junit-3.8.1-javadoc.jar,junit-3.8.1-sources.jar through some plug-ins, so that the accessory component has its own unique coordinates.

Of the above five elements, groupId, artifactId, and version must be defined, packaging is optional (default is jar), while classfier cannot be defined directly and needs to be used in conjunction with plug-ins.

Why does Maven use coordinates?

There are a lot of builds in the Maven world, and we need to find a unified specification that uniquely identifies a build.

With a unified specification, the search can be handed over to the machine.

Maven dependency management

Dependence

Dependence is usually shown as: I need something from you, just like couples depend on each other, couples depend on each other, people depend on water, people depend on food, and so on.

In Maven, it is shown that each class of the b.jar package is used in the project, and the project depends on b.jar at this time.

Complex relationships are multi-layer dependencies: a.jar packages depend on b.jar packages, and it is possible that b.jar packages depend on c.jar. This phenomenon can also be called dependent transitivity.

Our project relies on b.jar indirectly.

Dependent configuration

The example of dependency configuration in Maven is as follows:

Junit junit 4.9 test com.tian.maven user-service 0.0.1-SNAPSHOT compile

Dependent range

The so-called dependency scope refers to what we need to rely on the jar. Some need it when compiling, and some need to wait when testing.

There are six types of dependency range scope:

"compile" default compilation dependency scope. All three classpath are valid for compiling, testing, and running. That is, to use the dependent jar package at compile, test, and run time

The "test" test depends on scope. Valid only for testing classpath. Such dependencies cannot be used when compiling and running a project, typically JUnit, which is only needed when compiling and running test code

"provided" already provides a scope of dependency. The tested classpath is valid for compilation, but not for run. Because it is already provided by the container, such as servlet-api.jar, which is needed during compilation and testing, but at run time, the web container is already provided, so there is no need for maven to help introduce it.

The "runtime" runtime depends on scope, and using this scope-dependent maven dependency is valid for compiling tests, running tests, and running the project's classpath, but not when compiling the main code, such as the jdbc driver implementation, which requires a specific jdbc driver implementation at run time.

The "system" system depends on the scope, and when using the system scope dependency, you must specify the path to the dependent file through the systemPath element, and do not rely on Maven repository parsing, so it may cause the construction to be unportable (that is, there may be no problem on your computer, but it is not clear on other people's computers), somewhat similar to provided, note that this system is used cautiously.

${java.home} / lib/rt.jar

"import" only pom supports this scope on type dependencies in this section. It indicates that the dependency will be replaced by a list of valid dependencies in the specified pom section. Because they have been replaced, the scoped dependency import does not actually participate in restricting the transitivity of dependencies, and is more used in springboot and springcloud.

Among the above six ranges, compile, test, runtime and provided are commonly used.

The dependency scope not only controls the relationship with the three classpath, but also affects transitive dependencies. The dependency diagram is as follows:

Note that this is expected to be run-time scope, so all compilation dependencies must be explicitly listed. However, if the library you rely on extends a class from another library, both must be available at compile time. Therefore, even if the compile-time dependencies are transitive, they remain in the compilation scope.

Maven warehouse management

Maven warehouse

To uniformly store all Maven shared build locations, to put it bluntly, it is used to store jar packages. Every time we compile locally, it is impossible to compile without corresponding jar packages. We need a lot of jar dependencies in a project, so we will know the importance of the warehouse.

Maven warehouse layout

Define a unique storage path for each build in the warehouse based on Maven coordinates, which is roughly:

GroupId/artifactId/version/artifactId-version.packaging

Local warehouse

In the previous article, there was only one local repository per user, which by default represents the user directory in ~ / .m2 / repository/,~. In order to facilitate management, we usually set up our own catalog, which is specially used to store the contents of the local warehouse. In this way, when we develop, we rely on that jar to go directly to our local warehouse repository to find it. If not, we will pull it from the central warehouse.

Central warehouse

Basically saved all the external development of jar packages, Maven default remote warehouse, (foreign website) URL address: http://search.maven.org/. There is also, for example, Ali's warehouse, when we are developing, due to network reasons, many people like to use Ali's warehouse: http://maven.aliyun.com.

At this time, the relationship between our local warehouse and the central warehouse:

Private service

Most companies build private servers, which is a special remote warehouse, which is set up in the local area network. For example, the company sets up a local area network, the company also sets up a warehouse, and then the developers directly use the private servers built by the company, which greatly reduces the network overhead and development costs (sometimes the external network access is very slow, it will waste everyone's development time).

In this way, developers will pull each jar package directly from the company's private server every time they need it, instead of using the external network to pull it from the central warehouse. In short, save time and save the network to start. And some enterprises still do not give the public network, at this time you know the importance of this private service.

After the addition of private service, the diagram of local warehouse + private server + central warehouse:

Interviews are also frequently asked: what is the relationship between the local warehouse, the private service and the central warehouse?

Maven lifecycle

The life cycle of Maven: the process from our project build to project release.

Description of each stage:

In order to complete the default lifecycle, these phases (including other lifecycle phases not listed above) will be executed sequentially.

Maven has three standard lifecycles:

Clean Lifecycle does some cleanup before actually building.

The core of the Default Lifecycle build, compilation, testing, packaging, deployment, and so on.

Site Lifecycle generates project reports, sites, and publishing sites.

These three standards are independent of each other. You can just call clean to clean up the working directory and just call site to generate the site. Of course, you can run mvn clean install site directly to run all three lifecycles.

When you run any phase, all the phases that precede it are run, which is why when we run mvn install, the code is compiled, tested, and packaged. In addition, Maven's plug-in mechanism is completely dependent on the life cycle of Maven, so it is important to understand the life cycle.

Maven plug-in

Maven doesn't do anything specific, but defines the phases and steps of the life cycle, which are done by plug-ins integrated into Maven.

The core of Maven only defines the abstract life cycle, and the specific tasks are left to the plug-in.

Each plug-in can achieve multiple functions, and each function is a plug-in goal.

The life cycle of the Maven is tied to the plug-in goal to accomplish a specific build task. For example, compile is a plug-in goal of the plug-in maven-compiler-plugin.

With regard to plug-ins, here is a general idea, and there will be an article devoted to Maven plug-ins.

Eliminate the need for dependence

Com.tian.maven my-maven 1.0.0 com.tian.maven your-maven

The above use of the exclusions element excludes the passing of my-maven- > your-maven dependencies, that is, my-maven- > your-maven is not passed to the current project.

There can be multiple exclusion elements in exclusions, and one or more dependent passes can be excluded. When declaring exclusion, you only need to write groupId and artifactId, and version can be omitted.

At this point, I believe you have a deeper understanding of "how to quickly grasp the core concepts of Maven". 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.