First, the relationship between aggregation and inheritance
Major polymerization in order to quickly build projects, mainly in order to eliminate duplication inheritance
Second, why should polymerization?
With the rapid development of technology and user requirements for various types of software more and more, the software itself has become more complex, and software designers began to use a variety of ways to develop, so there will be our layered architecture , sub-module development, to improve the clarity and code reuse. For in this feature, maven has also given a corresponding configuration.
Scenario one:
We in the development process, created more than two modules, each module is an independent maven project, we can compile and test runs independent of each module in the beginning, but with the increase in size and complexity of the project technology, we expect to use simple operations to complete the compilation work, which gives the arrangement Maven aggregation.
The so-called polymerization, by definition, the number of modules or projects aggregated together, we can build a Maven project --- aggregator dedicated to the work of polymerization.
When building the project, we should note the following:
1. The aggregator itself as a Maven project, it must have its own POM
2. It must be packaged way: pom
3. The introduction of a new element: modules --- module
4. Version: consistent aggregation module versions and polymerized versions module
5.relative path: the value of each module is a relative directory of the current POM
6. directory name: In order to facilitate quick positioning content, in which the directory module should be consistent with its artifactId (not a hard requirement Maven convention), in short, in which the directory module must be <module> modules are in the directory </ module > consistent.
7. customary convention: Construction For convenience, the polymerization generally project directory module in the topmost layer, other polymeric modules exist as a subdirectory. So that when we open the project, first to see is the aggregation module POM
8. content aggregation module reduced: content aggregation module is only a pom.xml file, it does not contain src / main / java, src / test / java directory, etc., because it is only a tool to build other modules, itself and no real content.
9. polymerization directory module and sub-modules: they may be a parent-child class, the structure may be parallel, of course, if a parallel structure, the aggregation module POM also need to make the appropriate changes.
Third, why should inherit?
Do object-oriented programming people will think this is a meaningless question, yes, inheritance is to avoid repetition, maven inheritance, too, it has another advantage is to make the project more secure
Scenario Two: We are in the process of project development, multiple modules may be independently developed, but multiple modules may rely on the same element, for example, each module requires a Junit, use spring when its core jar must have been the introduction, at compile time, maven-compiler-plugin plugins have been introduced
How to Configure Inheritance:
1. When it comes to succession is certainly a parent-child structure, then we create a parent project in the aggregator
2. <packaging>: as POM parent module , which must as a packaging type POM
3. Structure: The parent module just to help us eliminate duplication, so it does not need to src / main / java, src / test / java directory, etc.
4. The new element: <parent>, which is used in the sub-modules
Properties 5. <parent> element: <relativePath>: represents a relative path of POM parent module, when built, Maven will first check according relativePath parent POM, if not found, then find from the local repository
6.relativePath defaults: ../pom.xml
7. omitted groupId and sub-module version: you can not use the statement groupId and version, implicitly sub-module will inherit the parent module of two elements inherited sub-module
version 8.dependencyManagement declare dependencies can rely on a unified project. If the module is not a subclass declared dependency is used, does not have any effect.
POM element can be inherited
groupId: Project group ID, the item coordinate core elements
version: the core elements of the project versions, the project coordinates
description: project description of
organization: the organization of information items
inceptionYear: founding year of the project
url: URL address of project
developers: project developers information
contributors: contributor information project
distributionManagement: the project's deployment configuration
issueManagement: defective item tracking system information
ciManagement: continuous integration system project information
scm: version control system project information
mailingLists: mailing list of items of information
properties: custom maven attribute
dependencies: dependent project configuration
dependencyManagement: project dependency management configuration
repositories: warehouse configuration items
build: include project source directory configuration, output directory configuration, plug-in configuration, plug-in management configuration
reporting: including project report output directory configuration , reporting plug-in configuration, etc.
maven dependency management
We know that dependencies can be inherited, and this time we thought we rely occurred common elements transferred to the parent, so we have further optimized the configuration. But the problem has cropped up, if one day I created a new module, but the module does not need to rely on these parent, how to deal with this time?
Yes, maven dependency management is to solve this problem
Add a new element: dependencyManagement
From the above list we find dependencyManagement also can be inherited, which is precisely to meet our needs, both to allow the child to inherit the module configuration dependent parent module, but also ensures that rely on the use of sub-module flexibility
dependencyManagement features: dependencyManagement element disposed in neither parent is introduced will depend, does not give its dependent sub-module is introduced, only its configuration is inheritable
<dependencyManagement> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>${junit.version}</version> <scope>test</scope> </dependency> </dependencies> </dependencyManagement>
POM inherit these sub-module configuration: sub-modules inherit when these configurations, still have to declare groupId and artifactId, it indicates that the current configuration is inherited from a parent POM, which directly corresponds to the version of the parent POM resources
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</dependency>
</dependencies>
This can effectively prevent the use of multiple sub-modules inconsistent versions of dependent situation, help to reduce the risk of dependence conflict. Note: Only the sub-module configuration inheritance elements will really effective, otherwise it will not load maven is an element declared in the parent module.
Five, Maven plugin management
Add a new element: <pluginManagement>
This element and <dependencyManagement> similar, which is used for plug-in management.
Methods In the course of our project development, the introduction of plug-in will be frequent, so the solution is to use these complex configuration management plug-ins
We can make the following statement in the parent POM:
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId></groupId>
<artifactId></artifactId>
<version></version>
<executions>
<execution>
<id></id>
<goals>
<goal></goal>
</goals>
<phase></phase>
<configuration>
<source></source>
<target></target>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
</build>
In sub-module, we can directly inherit
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
</plugin>
</plugins>
</build>
We will find details on inheritance and <dependencyManagement> almost the same.
Fourth, aggregation and inheritance summary
When we understand the details of polymerization and inheritance, we will find:
For the aggregation module, it knows what modules are to be polymerized, and for the module to be polymerized, the polymerized whom they do not know, do not know it exists
For the parent POM inheritance, it is not know which sub-module inherits, for child POM, it must know who their father is POM
In some of the best practices we will find: POM is both a polymeric POM, and is the parent POM, do so mainly for the convenience.
Can be inherited POM elements
groupId: core elements of the project group ID, the item coordinates
version: version of the project, coordinates the project's core elements
description: project description of
organization: the organization of information items
inceptionYear: founding year of the project
URL project: url address
developers: a project developer information
contributors: contributor information project
distributionManagement: project deployment configuration
issueManagement: defect tracking system project information
ciManagement: continuous integration system project information
scm: version control system project information
mailing list item: mailingLists information
properties: self-maven attributes defined
dependencies: dependent on project configuration
dependencyManagement: dependency management configuration project
repositories: warehouse configuration items
build: include project source directory configuration, output directory configuration, plug-in configuration, plug-in management configuration
reporting: include report output directory of project configuration, reporting and other plug-in configuration --------------------- author: Tong Tong -Dragon source: CSDN original: https: //blog.csdn .net / wanghantong / article / details / Edition 36,427,411 Disclaimer: This article is a blogger original article, reproduced, please attach Bowen link!