1. What is Java POM modularization
In Java projects, and especially when using Maven as a build tool, "POM modularity" is an important concept that refers to splitting large projects into smaller, more manageable modules (or subprojects). Each module has its ownfile, which defines the module's build configuration, including dependencies, plug-ins, target platforms, etc.
1.1 POM（Project Object Model）
The POM is the core Maven project management and build file, which is usually a file namedThe POM file contains all the configuration information for the project that Maven uses to build the project, manage dependencies, and perform other build tasks.
1.2 Modularization
Modularization is a technique for breaking down software into a set of independent but interoperable modules. In a Maven project, modularization means breaking a large application or library into smaller components, each responsible for a specific set of functionality or business logic. These components (i.e., modules) can depend on each other through Maven's dependency management mechanism to form a complete application or library.
1.3 Benefits of Maven Modularized Projects
（1）reusability: Modules can be shared and reused by multiple projects.
（2）Easy to manage: After a large project is split into small modules, each module can be built and tested independently, thus simplifying the process of building and testing the entire project.
（3）explicit dependency: The dependencies between modules are clearly visible through the dependency declarations in the POM file.
（4）Teamwork: Different modules can be developed in parallel by different teams or developers, improving development efficiency.
（5）dexterity: Modularization makes the project more flexible, allowing modules to be added, removed or replaced more easily.
1.4 Structure of the Maven Modularization Project
A Maven modular project typically contains a parent POM file and multiple submodules. The parent POM file defines the build configuration and dependency management policies that are shared by all child modules. The child modules inherit the configuration from the parent POM and add specific configurations or dependencies as needed.
1.5 Examples
Suppose there is a file namedMyProjectof the Maven modularization project, which contains three submodules:common、module-acap (a poem)module-b. The directory structure of the project might look like the following:
MyProject/
|-- (Parent POM)
|-- common/
||- (parent POM) |-- src/ |- (parent POM)
|- src/ |- (parent POM)
| |- main/
| |- java/
| |- com/example/common/ |- |- |- src/ | |- main/ | |- java/
|-- module-a/
| |- main/ |- java/ |- com/example/common/ |- module-a/
| |- src/
| |- main/ |- java/ |- com/example/common/ |- module-a/
| |- java/ |- com/example/music/
| |- com/example/modulea/ |- |- |- src/ | |- main/ | |- java/
|-- module-b/
|-
|- src/ |- main/ |- java/
|- main/ |- java/ |- com/example/modulea/ |- module-b/
|-- java/ |-- com/example/moduleb/ |-- com/example/moduleb/
|-- com/example/moduleb/
In this example, theMyProject/is the parent POM file that defines the configuration and dependencies common to all child modules.common、module-acap (a poem)module-bare submodules that each contain their ownfiles and source code. These sub-modules can depend on each other through Maven's dependency mechanism, as well as on external libraries.
through modularization.MyProjectProjects become clearer, easier to manage and maintain. Developers can build and test each module independently without worrying about dependencies between them. At the same time, the modular structure also makes the project more flexible and can be more easily extended or modified according to the needs.
2. Java Pom two modules need to refer to each other method example
In a Maven project, when two modules (or sub-projects, as they are called) need to refer to each other, it usually means that there is a tight dependency between these two modules. However, Maven's regular dependency management does not directly support circular dependencies (i.e., A depends on B, which in turn depends on A), as this can lead to deadlocks during the build process. In most cases, however, direct circular dependencies can be avoided by redesigning the module structure or by taking advantage of Maven features such as aggregation and inheritance.
But suppose our scenario is reasonable, for example, two modules are responsible for different business logic, but do need to share some common classes or interfaces which are distributed among the two modules. In this case, we can consider extracting the shared parts into a new module and then make both modules dependent on this new module.
I will show a simplified example with two modulesmodule-arespond in singingmodule-bOrganized through Maven's Aggregation and Inheritance mechanisms, and assuming that they manage dependencies by sharing a common parent POM, rather than referencing each other directly.
2.1 Project structure
my-project/
|- (parent POM)
|-- module-a/
||- (parent POM) |- module-a/ |- (parent POM)
| |- src/
| |- main/
| |- java/
| |- com/example/modulea/ |- |- |- src/ | |- main/ | |- java/
|-- module-b/
||- main/ |- java/ |- com/example/modulea/ |- module-b/
| |- src/ |- main/ |- java/
| |- main/ |- java/ |- com/example/modulea/ |- module-b/
||- java/ |- com/example/modulea/ |- module-b/ |- |- src/ |- main/
| |-- com/example/moduleb/
|-- common/
|-- common/
|- main/ |- java/ |- com/example/moduleb/ |- common/
|-- main/ |-- java/ |-- com/example/moduleb/ |-- common/
|-- java/ |-- com/example/moduleb/ |-- common/
|-- com/example/common/
2.2 Parent POM (my-project/)
<project xmlns="/POM/4.0.0"
xmlns:xsi="http:///2001/XMLSchema-instance"
xsi:schemaLocation="/POM/4.0.0 /xsd/maven-4.0.">
<modelVersion>4.0.0</modelVersion>
<groupId></groupId>
<artifactId>my-project</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>pom</packaging>
<modules>
<module>module-a</module>
<module>module-b</module>
<module>common</module>
</modules>
</project>
2.3 common Modules (common/)
<project xmlns="/POM/4.0.0"
xmlns:xsi="http:///2001/XMLSchema-instance"
xsi:schemaLocation="/POM/4.0.0 /xsd/maven-4.0.">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId></groupId>
<artifactId>my-project</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>
<artifactId>common</artifactId>
<dependencies>
<!-- Here you can addcommonDependencies required by the module -->
</dependencies>
</project>
2.4 module-a cap (a poem)module-b of the POM file
The POM files for these two modules will be very similar, except for theirartifactIdand possibly some specific dependencies besides. They will all depend on thecommonModule.
<!-- in order tomodule-ae.g. -->
<project xmlns="/POM/4.0.0"
xmlns:xsi="http:///2001/XMLSchema-instance"
xsi:schemaLocation="/POM/4.0.0 /xsd/maven-4.0.">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId></groupId>
<artifactId>my-project</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>
<artifactId>module-a</artifactId>
<dependencies>
<dependency>
<groupId></groupId>
<artifactId>common</artifactId>
<version>${}</version>
</dependency>
<!-- Other dependencies -->
</dependencies>
</project>
2.5 Conclusion
In this example, themodule-acap (a poem)module-bInstead of referencing each other directly, they do so by sharing acommonmodules to avoid circular dependencies. This is the recommended way to handle inter-module dependencies in Maven projects. If it is indeed necessary for two modules to reference each other directly, then it may be necessary to rethink our project structure or design patterns.
3. How to use Maven modularization
Modularization with Maven is a way to break large projects into smaller, more manageable parts. Each module is a separate Maven project with its ownfiles, but can be associated with other modules through Maven's inheritance and aggregation features. Here are the basic steps on how to modularize with Maven:
3.1 Creating a Parent POM
First, we need to create a parent POM (), which will serve as a common configuration template for all child modules. The parent POM usually does not contain source code, but defines configurations common to the project, such as dependency management, plugin configurations, target platforms, etc.
<! -- Parent POM (located in the project root directory) -- >!
<project xmlns="/POM/4.0.0"
xmlns:xsi="http:///2001/XMLSchema-instance"
xsi:schemaLocation="/POM/4.0.0 /xsd/maven-4.0.">
<modelVersion>4.0.0</modelVersion>
<groupId></groupId>
<artifactId>my-project-parent</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>pom</packaging>
<! -- Dependency Management -->
<dependencyManagement>.
<dependencies>.
<! -- Define here the dependencies and their versions that may be required by submodules -->
</dependencies>
</dependencyManagement>
<! -- Plugin management -->
<build>
<pluginManagement>
<! -- Plugins and their configurations that may be needed during the build process are defined here --> </pluginManagement> <!
</pluginManagement>
</build>
<! -- List of modules -->
<modules>
<module>module-a</module>
<module> module-b</module>
<! -- Other submodules -->
</modules>
</project>
Attention:<packaging>pom</packaging>Indicates that this is an aggregation POM, which does not build any actual products, but is used to aggregate and manage other modules.
3.2 Creating sub-modules
Then, we need to create submodules in the parent POM's sibling directory (or in any subdirectory specified). Each submodule should have its ownfile and usually inherits from the parent POM.
<! -- POM for submodule A (located in module-a directory) -->
<project xmlns="/POM/4.0.0"
xmlns:xsi="http:///2001/XMLSchema-instance"
xsi:schemaLocation="/POM/4.0.0 /xsd/maven-4.0.">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId> </groupId>
<artifactId>my-project-parent</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>
<artifactId>module-a</artifactId>.
<! -- Dependencies (if needed) -->!
<dependencies>.
<! -- Specific dependencies can be declared here, and version numbers can be inherited from the parent POM -->
</dependencies>
<! -- Other configuration -->
</project>
3.3 Constructing the project
Run the Maven command in the directory where the parent POM is located, and Maven will automatically find and build all the files listed in the<modules>sub-module under the label.
bash copy code
mvn clean install
This command will first clean up the files generated by the previous build, and then compile, test, and install all submodules into the local Maven repository.
3.4 Dependency Management
defined in the parent POM<dependencyManagement>section allows us to specify dependencies and their version numbers without actually introducing them in the parent POM. Child modules can inherit these dependencies and their version numbers by declaring the same dependencies (excluding version numbers).
3.5 Plug-in Management
Similarly.<pluginManagement>section allows us to define plugins and their configurations in the parent POM, but not to actually implement these plugins in the parent POM. Child modules can simplify the plugin configuration process by inheriting these plugin configurations.
3.6 Conclusion
With Maven modularization, we can break down large projects into smaller, more manageable parts while taking advantage of Maven's inheritance and aggregation features to share configurations and dependencies. This helps to improve the maintainability, reusability, and extensibility of the project.