First, aggregation
Suppose there are two modules: Account-email and account-persist; the ability to build these two modules with one command requires the creation of an additional module: Account-aggregator Build all the modules of the whole project through Account-aggregator, and the module itself is a MAVEN project with its own POM file; Note the aggregation modulethe value of the Account-aggregator packaging method packaging must be Pom, as follows:Note that the directory structure of the aggregation module and other modules is generally a parent-child relationship, as shown in the above Pom. It is not necessary, however, to be aware of pointing to the correct module directory (relative path in modules/module). At this point, you can run commands from the aggregation module to build each module, and build it in the reactor build sequence that will be described later:
mvn clean install
Second, the purpose of succession: To extract duplicate configuration, to a certain extent, eliminate duplication. Step: 1, inunder Account-aggregator, create a directory account-parent the most parent module, and build the Pom.xml file under the parent directory as follows:
Note that the packaging must be pom; In addition, the parent module does not itself contain project files other than POM (such as folders that do not need Src/main/java) in order to eliminate the duplication of the configuration. 2. Other modules inherit the parent module, such as the Pom.xml configuration in submodule account-email: note Gav: The submodule can inherit GroupID and/or version of the parent module, or it can explicitly declare a value that is not the same as the parent module; The Artifactid must be explicitly declared in the child element and different from the parent module. In addition, there are many POM elements that can be inherited, not just gav. 3. Add the account-parent to the aggregation account-aggregator as follows: Dependency management: MAVEN provides dependencymanagement elements that allow the submodule to inherit the dependency configuration of the parent block, andensure that the submodule relies on the flexibility of use. A dependency declaration under the Dependencymanagement element does not introduce an actualdependencies, but it can constrain dependency usage under dependencies. For example, you can include in Account-parent:
Used heredependencymanagementa declared dependency does not introduce a dependency on account-parent, nor does itthe submodule is introduced to the dependency but this configuration is inherited, as in Account-email:
The dependency configuration in the above POM is simpler than the original, and all springframework dependencies are configured with only GroupID and Aitifactid, eliminating the version,junit dependency not only omitted version, but also omitted the scope of dependency. Using this dependency management mechanism does not seem to reduce the number of POM configurations, but it is strongly recommended to use thismethods. The main reason for this is that the parent Pom uses thedependencymanagementdeclaration relies on the ability to unifyversions that are dependent on the project scope, it does not occur that multiple submodules use dependent version inconsistencies and reduce dependency conflicts. Of courseIf the submodule does not declare a dependent use, even if the dependency is already in the parent Pom'sDependencymanagement, nor does it produce any actual effect. Plugin Management: MAVEN provides dependencymanagement elements to help manage dependencies, similarly, MAVEN provides plugThe inmanagement element helps manage plug-ins. The dependencies configured in this element do not cause the actual plug-in invocation behavior,When a true plugin element is configured in the POM and its GROUPLD and ARTIFACTLD are configured in Pluginmanagementwhen the plug-in matches,pluginmanagementconfiguration will affect the actual plug-in behavior. Iii. the relationship between aggregation and inheritance the aggregation and inheritance in a multi-module MAVEN project is actually twoconcept, the purpose of which is entirely different. The former is mainly designed to facilitate the rapid construction of projects, the latter mainly to eliminaterepeat configuration;For an aggregation module, it knows that some of the modules are aggregated, but that this aggregated module does not knowthe existence of the module;For the parent pom of an inheritance relationship, it does not know which of the submodules it inherits from, but those submodules must beknow what your Father Pom is. In the actual project, the reader will find that a POM is both an aggregate pom and a parent pom, which is mainly for convenience. Iv. the agreement is better than the configuration definition: Maven advocates "Convention over Configuration" (Convention over config). This is not to say that the rules that the MAVEN convention ignores the user-configured rules, but rather that the user is not recommended to configure some rules, but instead uses the agreed rules. As Maven defaults to the user's project: Of course, MAVEN allows custom source directories: Reason: Super Pom any maven project inherits a Pom implicitly, just as any Java class inherits the object class. The configuration in this inherited Pom is a convention that MAVEN advocates. Maven3, this super Pom file is under the Org/apache/maven/model/pom-4.0.0.xml path in Maven_home/lib/maven-model-builder-x.x.x.jar. For example, the definition of super pom about warehouses: Five, reactor definition: In a multi-module MAVEN term, the reactor (Reactor) is a construction structure consisting of all modules.for a single-module project, the reactor is the module itself. But for multi-module projects, the reactors containthe relationship between the module inheritance and dependency, which can automatically calculate a reasonable sequence of module construction. Principle: The actual order of construction is formed in this way: Maven orderedRead the Pom, if the POM is not dependent on the module, then build the module, or first build its dependency modeblock. If the dependency also relies on other modules, then the dependent dependency is built up first. The dependency between modules will make the reactor a non-circular graph (Directed acyclic graph,dag), each module is the diagram'snodes, which form a forward edge according to the lock relationship. This diagram does not allow loops, so whenmodule A relies on B, andwhen B is dependent on a, MAVEN will make an error. Cutting reactors: Sometimes users will want to build only certain modules in the complete reactor, that is, to cut the reactors. Such as:
mvn clean install -pl account-email,account-persist
From for notes (Wiz)
"Maven Combat" notes -5-pom aggregation and inheritance
