Software designers often divide software modules in various ways to achieve clearer design and higher reusability. When applying Maven to a real project, you also need to divide the project into different modules. The aggregation feature of Maven can aggregate various modules of the project and build them together. The Inheritance feature of Maven can help extract the same dependencies and plug-ins of each module, while simplifying the Pom, it can also promote the consistency of configuration of each module.
<Maven practice>The book implements two modules: account-email and account-persist to implement a user-registered project. In this article, we also use this example to describe aggregation and inheritance.
Aggregation:Because of the existence of the account-email and account-persist modules, a requirement arises: we want to build two projects at a time, instead of executing the MVN command in the directory of the two modules. Maven aggregation (or multi-module) serves this requirement. We need to create an additional module named account-aggregator, and then build all modules of the entire project through this module. Account-aggregator itself acts as a Maven project and has its own Pom. However, as an aggregation project, its pom has a special place. The following is the Pom. XML content of account-aggregator.
<?xml version="1.0" encoding="UTF-8"?><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/maven-v4_0_0.xsd"><modelVersion>4.0.0</modelVersion> <groupId>com.juvenxu.mvnbook.account</groupId> <artifactId>account-aggregator</artifactId> <version>1.0.0-SNAPSHOT</version> <packaging>pom</packaging> <name>Account Aggregator</name> <modules> <module>account-email</module> <module>account-persist</module> <modules> </project>
It should be noted that for an aggregation module, the value of packaging in packaging mode must be POM; otherwise, it cannot be constructed. <
Modules> Elements are the core configuration for aggregation. You can declare any number of module elements in a Maven project packaged in POM to achieve module aggregation. The value of each module is a relative directory of the current pom. To facilitate project construction, the aggregation module is usually placed at the top level of the project directory, and other modules exist as subdirectories of the aggregation module, so that when the user obtains the source code, the first thing we can see is the POM of the aggregation module. We don't need to look for the aggregation module from multiple modules to build the entire project. Account-aggregator does not have directories such as src/main/Java and src/test/Java, because the aggregation module is only a tool to help aggregate other modules, and it does not have any substantive content. We can run the MVN clean install command in the aggregation module to check how the aggregation module is built. As you can see, MAVEN will first parse the aggregation module pom, analyze the modules to be built, and calculate a reactor build order, and then build each module in sequence. The reactor is a construction structure composed of all modules. The Maven reactors will be explained in detail later.
Inheritance:In object-oriented design, programmers can establish a type of parent-child structure, and declare some fields and methods in the parent class for subclass inheritance, so that they can achieve "one declaration, multiple use ". Similarly, we need to create a parent-child structure, and then declare some configurations in the parent Pom for the Child POM to inherit, in order to achieve the goal of "One declaration, multiple use. The pom content of the parent module is similar to that of the aggregation module. As the parent module pom, the packaging type must also be POM. Because the parent module only serves to help eliminate repeated configurations, it does not contain project files except pom, and does not need src/main/Java or other folders. In the sub-module pom, use
ParentThe element declares the parent module. The child elements groupid, artifactid, and version in the parent specify the coordinates of the parent module. These three elements are required. Element relativepath indicates the relative path of the parent module pom. When a project is built, Maven first checks the parent POM Based on relativepath. If no parent Pom is found, it searches for the parent pom from the local repository. The default value of relativepath is ../POM. xml. That is to say, the default parent pom of Maven is under the directory of the previous layer.
Inherited pom elements:Some elements of the parent POM can be inherited by the Pom. The following is a simple description:
- Groupid: Project Group ID, core element of project coordinates
- Version: Project version, the core factor of project coordinates
- Description: Project Description
- Organization: organization information of a project
- Inceptionyear: the year when the project was created
- URL: the URL of the project.
- Developers: project developer information
- Contributors: Project contributor Information
- Distributionmanagement: project deployment configuration
- Issuemanagement: Project defect Tracking System Information
- Cimanagement: continuous integration system information of the project
- SCM: Project version control system Xixi
- Malilinglists: Project email list information
- Properties: Custom Maven attributes
- Dependencies: Project dependency Configuration
- Dependencymanagement: dependency management configuration of the project
- Repositories: Repository configuration of the project
- Build: Includes source code directory configuration, output directory configuration, plug-in configuration, plug-in management configuration, etc.
- Reporting: includes the report output directory configuration and report plug-in configuration of the project.
Dependency management:The denpencymanagement element provided by Maven not only allows the sub-module to inherit the dependency configuration of the parent module, but also ensures the flexibility of sub-module dependency usage. The dependency declaration under the dependencymanagement element does not introduce actual dependencies, but it can constrain the dependency usage under dependencies. The parent module declares dependencies in dependencymanagement. The child module inherits the dependencymanagement configuration in the parent module. The complete dependency declaration is already included in the parent pom, the sub-Pom only needs to configure a simple groupid and artifactid to obtain the corresponding dependency information and introduce the correct dependency. Although this dependency mechanism cannot reduce the configuration of POM too much, the dependencymanagement statement can unify the dependent versions in the project scope. After the dependency version is declared in the parent pom, when a sub-module uses dependency, it does not need to declare the version, so that multiple sub-modules use different dependent versions. This helps reduce the chance of dependency conflicts. If the sub-module does not declare the use of the dependency, even if the dependency has been declared in the dependencymanagement of the parent pom, no actual effect will be produced.
Import dependency scope:The import dependency scope must be used under the dependencymanagement element. dependencies using this range usually point to a pom, the role is to import the dependencymanagement configuration in the target POM and merge it into the dependencymanagement element of the current pom. For example, if we want to use the dependencymanagement configuration exactly the same as that of another module, in addition to copying the configuration or inheriting the two methods, we can also use the import range dependency to import the configuration. The Code is as follows:
<dependencyManagemen> <dependencies> <denpendency> <groupId>com.juvenxu.mvnbook.account</groupId> <artifactId>account-parent</artifactId> <version>1.0-SNAPSHOT</version> <type>pom</type> <scope>import</scope> <denpendency> <dependencies><dependencyManagement>
Because of its particularity, the import scope dependency is generally directed to a module with the packaging type POM. If multiple projects use the same dependency version, you can define a pom that uses dependencymanagement to manage dependencies, and then import these dependency management configurations in each project.
Plugin management:Maven also provides the pluginmanagement element to help manage plug-ins. The use of plug-ins is similar to that of dependency management. If the sub-module requires different plug-in configurations, you can configure it to overwrite the pluginmanagement configurations of the parent module. When multiple modules in the project have the same plug-in configuration, the configuration should be moved to the pluginmanagement element of the parent pom. The pluginmanagement element of the parent pom should be used to uniformly declare the version of the plug-in even if the specific configurations of the same plug-in are different for each module. You can even declare the versions of all the plug-ins used in the pluginmanagement element of the parent Pom. The version information is not configured when the sub-module uses the plug-in. In this way, you can unify the plug-in version of the project, it is easier to maintain and avoid potential plug-ins that are inconsistent or unstable.
The relationship between aggregation and inheritance:In actual projects, we usually put the aggregation module and the parent module together for implementation.
Reactors:In a multi-module Maven project, reactor refers to a construction structure composed of all modules. For a single-Module Project, the reactor is the module itself, but for multi-module projects, the reactors contain the inheritance and dependency relationship between modules, in this way, a reasonable module building sequence can be automatically calculated.
Construction Sequence of reactors:The actual building order is formed as follows: Maven reads POM in order. If the POM does not have a dependency module, the module is built. Otherwise, the dependency module is built first, if the dependency is dependent on other modules, the dependency is further built. The dependency between modules forms a directed non-circular diagram (DAG) of the reactors. Each module is the node of the diagram, and the dependency forms a directed edge. This figure does not allow loops. Therefore, when module A depends on Module B and Module B depends on module A, Maven reports an error.
Maven Study Notes (7): Aggregation and inheritance
