Blowing water in a bowl
Maven aggregation module:
Because Maven advocates modular programming, it will divide multiple projects into multiple modules. If all functions and modules are written in one project, it is inconvenient for expansion, upgrade, modification, viewing and team development, and it is also inconvenient for the reuse of modules.
Maven advocates splitting a project into multiple projects, and each project completes a module or function. These projects are like parts, which are developed separately. Dividing into multiple projects is also convenient for maintenance and division of labor.
Each project module can be connected in series through the pom configuration file. For example, after configuring the pom file, project A can directly call the code of project B, and project C can call the code of project A and project B.
Because the project is divided into multiple modules, even if it can be connected in series, it cannot be managed in a unified way. If [Learn Java, go to Kaige School kaige123.com] a module lacks a compilation environment or lacks some dependent packages, the overall situation will appear. Therefore, we need a separate project to manage these modules, so as to achieve unified management. After unified management of these scattered projects, we can compile, test or run them in a unified manner. This is the aggregation module.
According to Maven's aggregation method, all projects are placed in one directory, and then managed through a pom file, but it is troublesome to do this in Eclipse or other development tools, and it needs to be operated manually. But we can create a separate pom project to implement this aggregation management:
After the creation is complete, there is only one src folder and pom file in this project:
Then edit the pom configuration file for module mapping:
Because you can only see the other three projects if you go to the previous directory
Then you can compile, test, or run in unity:
Maven inheritance:
Maven inheritance is to inherit the dependency package configured by the parent node. For example, the parent node is configured with the JUnit dependency package. In this case, as long as the project that inherits it will automatically download the dependency package, you do not need to configure it yourself.
This parent node is a pom project, so we can directly use the management project as the parent node.
Example:
Because the above approach will cause all projects that inherit this parent node to download the dependency package configured by this parent node, but if some projects do not necessarily need this dependency package, declare this dependency package as no need to automatically download dependencies:
Then the project that inherits this parent node will not be downloaded automatically:
If there is a project that needs to configure a dependency package configured by this parent node that does not need to be automatically downloaded, just write a dependency, but you do not need to write the version number of this dependency package:
Maven's life cycle:
An important reason why Maven is powerful is that it has a very complete life cycle model (lifecycle). This life cycle can be understood from two aspects. First, as the name suggests, every step of running Maven is determined by it. To define, this predefined default behavior makes it easy for us to use Maven, in contrast, every step of Ant requires you to define it manually. Second, this model is a standard. In different projects, the interface for using Maven is the same, so there is no need to carefully understand the construction of each project. In general, commands such as mvn clean install are common . I think, it must have absorbed the experience of many projects, Maven can define such a perfect model.
Maven has three sets of independent life cycles. Please note that the "three sets" mentioned here are "independent of each other". It is easy for beginners to regard the life cycle of Maven as a whole, but it is not. The three sets of life cycles are:
Clean Lifecycle does some cleanup work before the actual build.
The core part of the Default Lifecycle build, compile, test, package, deploy, and more.
Site Lifecycle generates project reports, sites, publishing sites.
Again, they are independent of each other, you can just call clean to clean the working directory, and just call site to generate the site. Of course you can also run mvn clean install site directly to run all three life cycles.
Each life cycle consists of a set of phases (Phase), and the commands we usually enter on the command line always correspond to a specific phase. For example, run mvn clean , which is a phase of the Clean lifecycle. A little round? To know that there is a Clean life cycle, there is also a clean phase. The Clean life cycle consists of three phases:
pre-clean performs some work that needs to be done before clean
clean removes all files generated by the last build post-clean executes some work branches
that need to be done immediately after clean :
The clean in mvn clean is the above clean. In a life cycle, when running a certain stage, all stages before it will be run, that is to say, mvn clean is equivalent to mvn pre-clean clean, if we run mvn post-clean, then pre-clean, clean will be run. This is a very important rule of Maven, which can greatly simplify the input of the command line.
Let's take a look at the various phases of the Site life cycle:
pre-site performs some work that needs to be done before generating site documentation site generates site documentation for the
project
post-site performs some work that needs to be done after generating site documentation and provides Preparing for deployment
site-deploy deploys the generated site documentation to a specific server
branch map:
The site stage and site-deploy stage are often used here to generate and publish Maven sites. This is a very powerful feature of Maven. Manager prefers it, and documents and statistics are automatically generated, which is very nice.
Finally, let's take a look at the most important Default life cycle of Maven. Most of the work occurs in this life cycle. Here, I only explain some of the more important and commonly used stages:
Remember, when any stage is run, all stages before it will be run, which is why when we run mvn install, the code will be compiled, tested, and packaged.
Maven plugin:
Maven's core distribution package is less than 3MB in size. Maven will download and use plugins when needed. For the plugin itself, in order to reuse code, it can often complete multiple tasks. Maven's life cycle and plug-ins are bound to each other to complete the actual [Learn Java, go to Kaige School kaige123.com] construction task. Specifically, the phases of the life cycle are bound to the goals of the plugin to complete a specific build task.
A plugin can usually accomplish multiple tasks, and each task is called a goal of the plugin. For example, when the mvn install command is executed, the called plugin and the executed plugin target are as follows:
Maven's life cycle is abstract, and plug-ins are actually required to complete tasks. This process is accomplished by binding the goals of the plug-ins to specific phases of the life cycle. For example, bind the compile goal of the maven-compiler-plugin plugin to the compile phase of the default life cycle to complete the source code compilation of the project:
Built-in binding:
Maven binds plugin goals by default for some phases of the life cycle, because different projects have different packaging methods such as jar, war, and pom, so there are different binding relationships. The binding relationship of the jar package packaging method of the default life cycle is as follows:
In the second column, after the colon is the bound plugin target, and before the colon is the prefix of the plugin, which is a simplified way to configure and use the plugin. Plugin Prefix.
Custom binding:
Users can bind any plugin goal to any life cycle stage as needed, such as: bind the jar-no-fork goal of maven-source-plugin to the package stage of the default life cycle, so that later When executing the mvn package command to package the project, the source code package will be executed after the package phase, and a source code package in the form of ehcache-core-2.5.0-sources.jar will be generated.
Configuration Plugin
The Maven plugin is highly extensible and can be easily customized. For example: configure the JDK version of the maven-compiler-plugin plugin to compile the source code to 1.7:
Overall grammar rules:
