Author: George Ma
Original link: http://www.oracle.com/technetwork/cn/community/java/apache-maven-getting-started-2-405568-zhs.html
The first article gave an overview of Apache Maven, its download and installation, and ran a simple example. Then after having a little contact with maven, the next step is to understand the core concepts of maven, so as to be able to use maven with ease.
Next, we introduce the following core concepts:
- POM (Project Object Model)
- Maven plugin
- Maven Lifecycle
- Maven dependency management
- Maven library
POM (Project Object Model)
All configuration for a project is placed in the POM file: defining the project's type, name, managing dependencies, customizing the behavior of plugins, and so on. For example, you can configure the compiler plugin to use java 1.5 to compile.
Now take a look at the POM of the example in the first post
XML code
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.helloworld</groupId>
<artifactId>helloworld</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>
<name>helloworld</name>
<url>http://maven.apache.org</url>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
In POM, groupId, artifactId, packaging, version are called maven coordinates, which can uniquely identify a project. With maven coordinates, we can use it to specify other projects, plugins, or parent projects that our project depends on. Generally maven coordinates are written in the following format:
groupId:artifactId:packaging:version
Like our example would be written as:
com.mycompany.helloworld: helloworld: jar: 1.0-SNAPSHOT
Our helloworld example is simple, but large projects are generally divided into several sub-projects. In this case, each subproject would have its own POM file, and then they would have a common parent project. In this way, all child projects can be built as long as the parent project is built. The POM of the child project inherits the POM of the parent project. Also, all POMs inherit a Super-POM. Super-POM sets some default values, such as the default directory structure mentioned in the first article , default plugins, etc. It follows the principle of convention over configuration. So even though our POM is simple, it's only part of what you can see. POMs at runtime are much more complex. If you want to see the full contents of the POM at runtime, you can run the following command:
$mvn help:effective-pom
Maven plugin
In the first article , we used the mvn archetype:generate command to generate a project. So what does archetype:generate mean here? archetype is the name of a plugin, and generate is the name of the goal. The meaning of this command is to tell maven to execute the generate goal of the archetype plugin. Plugin goals are usually written as pluginId:goalId
A goal is a unit of work, while a plugin is a collection of one or more goals. For example, Jar plugin, Compiler plugin, Surefire plugin, etc. As you can tell from the name, the Jar plugin contains goals for building Jar files, and the Compiler plugin contains goals for compiling source code and unit test code. The Surefire plugin runs unit tests.
Seeing this, I guess you can understand that mvn itself doesn't do much, it doesn't know how to compile or package. It delegates the task of building to plugins. Plugins define common build logic and can be reused. The advantage of this is that once the plugin is updated, all maven users can get the update.
Maven Lifecycle
In the previous article , the second command we used was: mvn package. The package here is a maven life cycle phase (lifecycle phase). The life cycle refers to the construction process of the project, which includes a series of ordered phases, and a phase is a step in the construction process.
So what is the relationship between the lifecycle phases and the plugin goals mentioned above? Plugin goals can be bound to lifecycle phases. A lifecycle phase can bind multiple plugin goals. As maven steps through each stage in the build process, all plugin goals for that stage are executed.
Maven can support different life cycles, but the most commonly used is the default Maven lifecycle (default Maven lifecycle). If you haven't done any plugin configuration or customization on it, the mvn package command above will execute the plugin goals in the default lifecycle up to and including the package phase in turn:
-
process-resources 阶段：resources:resources
-
compile 阶段：compiler:compile
-
process-classes stage: (default no target)
-
process-test-resources stage: resources:testResources
-
test-compile 阶段：compiler:testCompile
-
test stage: surefire:test
-
prepare-package phase: (default no target)
-
package 阶段 ： jar: jar
Maven dependency management
We said before that maven coordinates can identify a project. In other words, we can use it to resolve dependencies. In a POM, dependencies are defined in the dependencies section. In the POM example above, we used dependencies to define a dependency on junit:
XML code
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
This example is very simple, but in actual development we will have much more complex dependencies, because the dependent jar files will have their own dependencies. So do we need to define those indirectly dependent jar files in the POM? The answer is no, because maven provides transitive dependencies.
The so-called transitive dependency means that maven will check the dependent jar file and incorporate its dependencies into the final resolved dependency chain. For the above junit dependencies, if you look at the maven native repository (we'll explain the maven repository shortly) ~/.m2/repository/junit/junit/3.8.1/ ,
You will find that maven not only downloaded junit-3.8.1.jar, but also its POM file. This way maven can check the junit dependencies and include the dependencies it needs.
In the dependencies section of the POM, scope determines the scope of the dependencies. In our example, the scope of junit is test, so it will only be added to the classpath when the compiler:testCompile and surefire:test targets are executed, and junit will not be available when the compiler:compile target is executed.
We can also specify scope as provided, which means that the JDK or container will provide the required jar files. For example, when doing web application development, we need the servlet API jar file when compiling, but we don't need to put this jar file in the WAR when packaging, because the servlet container or application server will provide it.
The default value of scope is compile, which means that it will be included in the classpath at all times, and will also be included when packaging.
Maven library
When running the maven command for the first time, you need an internet connection because it downloads some files from the internet. So where is it downloaded from? It is downloaded from the maven default remote repository (http://repo1.maven.org/maven2). This remote repository has maven core plugins and jar files available for download.
But not all jar files can be downloaded from the default remote repository, such as our own developed projects. At this point, there are two options: either set up a custom library within the company, or manually download and install the required jar files to the local library.
The local library refers to the copy stored on the local machine after maven downloads the plug-in or jar file. On Linux, its location is ~/.m2/repository, on Windows XP, at C:\Documents and Settings\username\.m2\repository, on Windows 7, at C:\Users\username\.m2 \repository. When maven looks for the required jar file, it will first look in the local library, and only if it cannot find it, will it look in the remote library.
Running the following command will install our helloworld project into the local repository:
$mvn install
Once a project is installed into the native repository, your other projects can establish dependencies with this project through maven coordinates. For example, if I now have a new project that needs to use helloworld, after running the mvn install command above, I can build the dependencies as follows:
XML code
<dependency> <groupId>com.mycompany.helloworld</groupId> <artifactId>helloworld</artifactId> <version>1.0-SNAPSHOT</version> </dependency>
Well, the core concepts of maven are briefly introduced here. As for how to use maven in Eclipse, there are many online, just google it.