Multi-Module Projects and Plugins

Why multiple modules

A large system is often split into modules – for example core, web and batch – that build together but stay separately compilable and reusable. A parent POM ties them together and shares configuration.

<!-- parent pom.xml -->
<packaging>pom</packaging>
<modules>
  <module>core</module>
  <module>web</module>
</modules>

Building the parent builds every module in the correct order, and a module can depend on another (web depends on core) by its GAV.

Managing versions centrally

Declare dependency versions once in the parent’s <dependencyManagement>; child modules then reference dependencies without a version, guaranteeing every module uses the same one:

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.google.code.gson</groupId>
      <artifactId>gson</artifactId>
      <version>2.11.0</version>
    </dependency>
  </dependencies>
</dependencyManagement>

Plugins do the work

Maven’s phases are actually carried out by plugins bound to them – the compiler plugin compiles, the surefire plugin runs tests. You configure or add plugins to customise the build:

<build>
  <plugins>
    <plugin>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-maven-plugin</artifactId>
    </plugin>
  </plugins>
</build>

Common plugins build an executable Spring Boot jar, create a shaded/fat jar, generate code, or check code style. Gradle offers the same power through its plugins block.

Key points

• Split large projects into modules under a parent POM that builds them in order.
• <dependencyManagement> centralises versions so all modules agree.
• Plugins carry out the build; add or configure them to customise it.
• Both Maven and Gradle support multi-module builds and rich plugin ecosystems.