Maven aggregation modules and the life cycle of inheritance and maven

End Bowl blowing water

Maven aggregation module: because MAVEN advocates modular programming, it divides multiple projects into Modules. If all the functions and modules are written in a project, it is not easy to expand, upgrade, modify, View and Team development, and it is not convenient for the reuse of Modules. MAVEN is advocating to split a project into multiple projects, each project to complete a module or function, these projects like parts, respectively, to develop, divided into several projects are also convenient for maintenance and division of Labor. Each engineering module can be concatenated through the POM configuration file, for example, after the pom file is configured, a project can directly invoke the code of Project b, and C can invoke the code of Project A and B. Because the project is split into multiple modules, even if it can be connected in a single unified management, if "learning java, to the kaige123.com" a module is missing the compilation environment or missing some of the dependency package will be the overall error, so we need a separate project to manage these modules, In order to achieve unified management, these scattered projects unified management can be unified to compile, test or run, This is the aggregation module. According to Maven's aggregation method is to put all the project in a directory, and then unified through a pom file to manage, but in eclipse or other development tools to do this is more troublesome, need to manually to Operate. But we can create a separate POM project to implement this aggregation management:

created, 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 in the previous Directory.

It can then be compiled, tested, or run uniformly:

Maven inheritance: The inheritance of Maven is to inherit the dependencies of the parent node configuration, for example, the parent node is configured with the JUnit dependency package, so that if the project that inherits it will automatically download this dependency package, it will not need to be configured Again. This parent node is a pom project, so we can use the management project as the parent node directly. Example:

Because the above practices will cause all projects that inherit this parent node to download the dependent packages configured by this parent node, if some projects do not have to require this dependency package, this dependency package is declared as requiring no automatic download dependencies:

Then the project that inherits this parent node is not automatically downloaded:

If there is a project to configure this parent node to configure a dependency package that does not need to be automatically downloaded, write a dependency, but do not need to write the version number of this dependent package:

Maven's Lifecycle: One important reason for Maven's strength is that it has a well-established life cycle model (lifecycle) that can be understood in two ways, first, as the name implies, and each step of running MAVEN is defined by it, This predefined default behavior makes it easy for us to use maven, and each step of ant is defined by you by hand. second, This model is a standard, in different projects, using Maven interface is the same, so do not have to carefully understand the construction of each project, in general, mvn clean install such command is GENERIC. I think the experience of many projects must be absorbed, and Maven can define such a perfect model. MAVEN has three sets of independent life cycles, Please note that this is said to be "three sets", and "mutual independence", beginners easily to the Maven life cycle as a whole, not actually. These three sets of life cycles are:? Clean Lifecycle Some cleanup before making a real build. The core part of the Default Lifecycle build, compile, test, package, deploy and so on.? Site Lifecycle generates project reports, sites, and publishing Sites. again, I emphasize that they are independent, you can simply call clean to clear the working directory, just call site to build the Site. Of course you can also run MVN clean install site to run all of these three sets of lifecycles directly. Each set of lifecycles consists of a set of stages (Phase), and the commands we normally enter at the command line always correspond to a specific stage. For example, running MVN clean, This clean is a phase of the clean life Cycle. A little bit around? Know that there is a clean life cycle and there is a clean phase. The clean life cycle consists of three phases:?pre-clean  performs some work that needs to be done before clean?clean  remove all previous build files?post-clean  Perform some work-branching diagrams that need to be completed immediately after clean:

Clean in mvn Clean is the clean that is above, and in a lifetime, at the time of running a phase, all phases before it are run, that is, 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 for maven, which can greatly simplify the input of the command Line. Take a look at each phase of the site lifecycle:? Pre-site do some work that needs to be done before the site document is generated? site Build Project Web documentation? Post-site perform some work that needs to be done after the site document is built, and prepare for deployment? si Te-deploy deploy the generated site document to a specific server on the branch map:

The site phase and the Site-deploy phase are often used here to generate and publish Maven sites, which is a pretty powerful feature of maven, and the manager prefers that documents and statistics are generated automatically and beautifully. finally, take a look at Maven's most important default life cycle, where most of the work takes place in this life cycle, where I only explain some of the more important and common phases:

remember, when you run any stage, all the stages in front of it will be run, which is why when we run MVN install, the code is compiled, tested, packaged.

Maven Plugin: Maven's Core bundle is less than 3MB in size, maven will download and use the plugin when needed, and for the plug-in itself, it can often accomplish multiple tasks in order to reuse the Code. The life cycle of Maven is tied to Plug-ins to complete the actual "learning java, to the kaige123.com academy" build Task. specifically, the phase of the lifecycle is tied to the target of the plug-in to accomplish a specific build Task. A plug-in can usually accomplish multiple tasks, each of which is called a target of a plugin. When executing the MVN install command, the plug-in and execution plug-in targets are called as Follows:

The life cycle of MAVEN is abstract and actually requires a plug-in to complete the task, which is done by binding the Plug-in's target (goal) to the specific phase of the lifecycle (phase). For example: bind the compile target of the Maven-compiler-plugin plug-in to the compile stage of the default life cycle to complete the Project's source code compilation:

Built-in bindings: maven binds plug-in targets by default for some lifecycle stages (phase), because different projects have different packaging methods, such as jar, war, pom, etc., So there are different binding relationships. The binding relationships for the package of jar packages for the default life cycle are as follows:

In the second column, after the colon is the binding plug-in target, preceded by the prefix of the plugin (prefix), is a simplified way to configure and use the Plug-in. Plugin Prefix.

Custom Bindings: users can bind any plug-in target to the stage of any life cycle as needed, such as binding Maven-source-plugin's Jar-no-fork target to the package stage of the default life cycle, so that later execution mvn When the package command packages a project, The source code is packaged after the package phase, generating a source bundle such as the Ehcache-core-2.5.0-sources.jar form.

The configuration plugin maven plugin is highly extensible and can be easily customized. For example: Configure the Maven-compiler-plugin plugin to compile the source code for JDK version 1.7:

The whole grammar rules:

Maven aggregation modules and the life cycle of inheritance and maven