Let's review, when we develop projects, a large project is often divided into multiple projects. For example, an e-commerce website may be divided into modules such as base and core. Each module is a project, and then different Business, such as product, order and other business modules, will also be a separate project, so the project and the project must be related. For example, the order module depends on the core module. In the past, when we did not use maven, we often used tools. For example, in eclipse, we could add project associations to the build path.
But when performing operations like unit testing, packaging, etc., we still have to operate on a per-project basis. When the number of projects is relatively small, we can still do it manually, but once there are more projects, it will be very cumbersome.
Maven naturally supports multiple modules. Maven aggregates the various modules of the project together by means of aggregation. When we perform a build for the aggregate project block, the modules included in the aggregate project will also perform corresponding build actions.
polymerization
Using aggregation, we generally build a maven project separately. This project has no business and is only used for aggregation, so it only needs a pom.xml file in the project root directory. The contents of the pom are as follows:
The pom content of the aggregation project is not much different from the pom file of the ordinary project, except that the packaging is pom. Additionally, we need to specify aggregated submodules via modules and its subelement module. In this way, when we execute the build process for the aggregated module, the sub-modules contained in it will also execute the corresponding build actions in turn, and there is no need to execute the build actions for each module individually.
inherit
Thinking about such a problem, we have a project that is divided into multiple modules, core, base, web, product, order, etc. Maybe our core module uses spring dependencies, and our web and order also use spring dependencies , In this way, we need to add spring's dependency configuration to the pom files of the core, web, and order projects. If there are not many third-party dependencies used, this is acceptable, but we often rely on many third-party jars, which will result in a lot of duplicate configurations.
Maven eliminates the duplicate configuration of pom through inheritance. This is somewhat similar to inheritance in java. The public operations are placed in the parent class, and the subclass will automatically have the corresponding function after inheritance.
To configure inheritance, we also need to define a separate parent project for child projects to inherit. In order to reduce the number of projects, we can merge the parent project and the aggregate project. We configure the required dependencies in the aggregation project through the dependency element, and then specify the parent project as the aggregation project in the sub-project:
In the child project, the parent element is used to specify the GAV and relative position of the parent project. In this way, the dependencies configured in the parent project do not need to be configured in the child project.
The following are inheritable pom elements in maven:
- groupId: project group id
- version: project version
- description: item description
- organization: the organization information of the project
- inceptionYear: the year the project was founded
- url: project URL address
- developers: developer information
- contributors: Contributor information
- distributionManagement: Deployment configuration
- issueManagement: bug tracking system information
- ciManagement: Continuous Integration System Information
- scm: version control system information
- mailingLists: Mailing list information
- properties: custom maven properties
- dependencies: dependency configuration
- dependencyManagement: dependency configuration management
- repositories: repository configuration
- build: including the source code directory configuration, output directory configuration, plug-in configuration, etc. of the project
- reporting: project's report output directory configuration, report plug-in configuration, etc.
dependency management
Let's think about such a problem again. Through inheritance, the configuration of repeated dependencies is indeed reduced. Therefore, we configure all dependency configurations in the parent module. After the submodule inherits, there is no need to configure any dependencies. In this case, some unnecessary dependencies are often introduced. For example, the core module uses the hibernate jar, we configure this dependency into the parent module, core inherits the parent module, then the hibernate jar is automatically introduced into the core, our web also inherits the parent module, and the web module will also The hibernate jar is automatically introduced, and the web does not need the hibernate jar. For this case, maven uses the dependencyManagement element to manage dependencies. The dependencyManagement element not only allows submodules to inherit the dependency configuration of the parent module, but also ensures the flexibility of submodule dependencies.
We use the dependencyManagement element to wrap it outside the dependencies element of the parent module, so that these dependency configurations in the parent module are just a definition and will not really introduce the corresponding dependencies. After the submodule inherits the parent module, it will not directly introduce the corresponding dependencies, and the configuration dependencies need to be displayed in the submodule, because the dependencies are already defined in the parent module at this time, so the dependencies in the submodule only need to configure groupId and artifactId That's it, no need to configure version.
In addition to the dependencyManagement element for dependency management, there is also the pluginManagement element for managing plugin dependencies.
property definition
Considering such a situation, many projects will use spring, but there are many modules in spring, we generally use the same version of the module, such as 3.2.5-RELEASE, then when we configure dependencies, each dependency specifies the version is 3.2.5-RELEASE. But one day, when we have to upgrade the version of spring, we need to modify the version of each dependency and change it to the new version. When the dependencies of the agreed version are relatively small, we can do this, but once the number of dependencies is large, manual operation is troublesome, and sometimes we even forget to modify the version of a dependency, resulting in inconsistent versions. For this case, we can use the way of attribute substitution.
In the pom, define the version of the dependency under the properties element, use the $ operation in the dependency to refer to the defined version, and modify the version later, just modify the version defined in the properties.