Top 5 Exciting Maven Multi-Module Project Ideas & Topics for Beginners [2021]

As any project gets more complex and layered, the correct way to manage it is by splitting it into different modules. In Maven, while it is possible to link these multiple projects as dependencies, it makes the build process a lot more complex. Therefore, the preferred approach is to structure the project as a multi-modular one and pass on the rest to Maven. 

Benefits of Using Multi-Modules in Maven

The significant advantage of using multi-modules instead of dependency injection or any other procedure is that it reduces duplication. To understand this better, suppose you’re working on an application that consists of two modules – let’s say the backend module and the frontend module. 

If you work on both of those modules and change certain functionalities that affect both the modules, you’ll need to build both the modules or components isolatedly without a specialised build tool. Or, you must write a script to compile the code, run tests, and display the final results.

Now, if the complexity increases even further and your project has more than two modules, it’ll become progressively harder to perform this task without a specialised build tool. Further, in real-world problems, your projects may require some Maven plugins to perform some crucial operations during the entire build lifecycle, share dependencies, or include other BOM projects. 

As a result of these challenges, the multi-modules in Maven are extremely helpful and let you build the application’s modules in a single command line. It also allows you to share a vast amount of data and configuration between multiple modules seamlessly. 

Also Read: Maven Interview Question Answer 

Key Terms to Know Regarding Multi-Module Projects in Maven

1. Parent POM (Project Object Module)

Each pom.xml file in Maven – for the support of inheritance – has a parent POM, known as the Super POM. This can be located in the Maven binaries, and you can also merge the two files to create the Effective POM. 

So, you can create your own pom.xml file to serve as the parent for your project. Once you’ve done that, you can add all the dependencies and configuration, set it as the parent of the child modules, and enable inheritance. Except for inheritance, Maven also provides aggregation. The Parent POM that leverages the aggregation functionality is known as the aggregate POM – this kind of POM declares the child modules explicitly in the pom.xml file. 

2. Submodules

Subprojects, also known as submodules, can be understood as standard Maven modules that inherit from the parent POM. Using inheritance, the modules share various dependencies and configurations. However, if you need to build the project quickly, you’ll need to explicitly declare the submodules in the Parent POM, making it the aggregate POM. 

3. The Simple Multi-Module Project

App and util are two modules that are contained in The Simple Multi-Module Project. The util module is required for providing a static method to join or append different strings using Apache Commons Lang library, and the app module is necessary to call the util module. Here’s a snippet from the app.java file: 

simple-multi/app/src/main/java/app/App.java

public class App {

    public static void main(String[] args) {

        System.out.println(new App().greet(“World!”));

    }

    public String greet(String name) {

        return Util.join(“Hello “, name);

    }

}

To build the project, run

$ cd simple-multi

$ mvn clean test

Maven’s code builder builds both the modules of your project in the correct order, performs the necessary tests, and outputs the results in an easily understandable summary format, like below: 

4. Structure of a Multi-Module Project

Here’s the layout of a simple Multi-Module project:

The simple-multi directory is the root directory and is present at the very top of the entire project. It contains the top-level POM (Parent POM), but this Parent POM doesn’t have any source folder. 

The top-level directory also contains app and util, which are regular Maven projects with directories and pom.xml file. 

The top-level POM and the module POM differ slightly from the regular POM. Let’s look in detail as to what they contain: 

5. Top Level POM

A Parent POM or a top-level POM is required by the Maven Multi-Module Project at the root directory. 

The top-level POM defines important aspects and project coordinates like artifactID, version, and groupID, as in any normal project. However, the packaging type for this is not in the usual war or jar format but as a pom. This is because the top-level module doesn’t contain any further source directory. The modules/module elements add the app and util modules. 

The content of this file include: 

simple-multi/pom.xml

<project xmlns=”http://maven.apache.org/POM/4.0.0″ xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”

xsi:schemaLocation=”http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd”>

  <modelVersion>4.0.0</modelVersion>

  <groupId>org.codetab</groupId>

  <artifactId>simple-multi</artifactId>

  <version>1.0</version>

  <packaging>pom</packaging>

  <modules>

      <module>app</module>

      <module>util</module>

  </modules>

</project>

To sum it up, the top-level POM specifies the pom packaging type and explicitly lists all the submodules. 

Keep in mind that you don’t need to worry about the ordering while declaring submodules in the Parent POM as Maven uses a Reactor to order the listed modules correctly. In the simple-multi, maven builds util module and then app since the app depends on util.

5. Module POM

The Module POM folder contains a regular source folder and its own pom.xml file. The content of this util/pom.xml are: 

util/pom.xml

<project xmlns=”http://maven.apache.org/POM/4.0.0″ xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”

   xsi:schemaLocation=”http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd”>

   <modelVersion>4.0.0</modelVersion>

   <parent>

       <groupId>org.codetab</groupId>

       <artifactId>simple-multi</artifactId>

       <version>1.0</version>

   </parent>

   <artifactId>util</artifactId>

   <properties>

       <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

       <maven.compiler.source>1.8</maven.compiler.source>

       <maven.compiler.target>1.8</maven.compiler.target>

   </properties>

   <dependencies>

       <dependency>

           <groupId>org.apache.commons</groupId>

           <artifactId>commons-lang3</artifactId>

           <version>3.6</version>

       </dependency>

       <dependency>

           <groupId>junit</groupId>

           <artifactId>junit</artifactId>

           <version>4.12</version>

           <scope>test</scope>

       </dependency>

   </dependencies>

</project>

There is no need to specify the groupID and version for the module as they’ll be inherited from the parent. The dependencies/dependency block defines the dependencies of util module – commons-lang3 and JUnit.

Now, let’s look at the app/pom.xml, which is quite similar to the util/pom.xml, except for the dependencies block, which is shown below:

app/pom.xml

….

<dependencies>

    <dependency>

        <groupId>org.codetab</groupId>

        <artifactId>util</artifactId>

        <version>1.0</version>

    </dependency>

    ….

</dependencies>

The app module uses methods from the util module, and for this, the app/pom.xml specifies util as the dependency.

To summarise all the things explained above:

The top-level project (parent project),

  • Defines top-level pom.xml, which specifies all the coordinates and submodules, and sets the packaging type as pom. 
  • Contains the further modules folders. 
  • Contains no source folders. 

Each of the module folders is nothing but regular Maven project directories. However, the pom.xml file contains:

  • The parent element specifies the module’s parent.
  • Module coordinates are specified in the artifactID element. GroupID and version are not mentioned as they are inherited from parent coordinates. 
  • The dependency, if one module depends on another, is mentioned in the dependencies/dependency element.

Executing the Multi-Module Project

$ mvn clean package command can be used to compile, test, and package the multi-module. However, to run it with the maven-exec-plugin requires the following steps: 

Run the following commands: 

$ cd simple-multi

$ mvn clean install

$ mvn exec:java -pl app -Dexec.mainClass=app.App

The install command installs the modules to your local repository, where you can then run the project. The option -pl app informs the exec plugin about the app module and runs its class app.App. Without install, the build process fails, as Maven cannot download and resolve the util module dependency.

However, it is quite cumbersome to install the project in a local repository each time before each run, especially when in the development phase. To ease that, you can directly execute the multi-module in Eclipse IDE without performing the install step. 

Conclusion

We hope this article helped you in getting started with the Maven Multi-Module process. As is with anything new, it’s just about getting the initial hang of it. Once you’ve understood the basic structure and functioning, you’ll be on your way to seamlessly manage multiple modules in Maven. 

If you’re interested to learn more about full-stack software development, check out upGrad & IIIT-B’s Executive PG Programme in Software Development – Specialisation in Full Stack Development which is designed for working professionals and offers 500+ hours of rigorous training, 9+ projects, and assignments, IIIT-B Alumni status, practical hands-on capstone projects & job assistance with top firms.

If you have any questions regarding the above article, let us know in the comments below!

Land on Your Dream Job

UPGRAD AND IIIT-BANGALORE'S SOFTWARE DEVELOPMENT PROGRAMME
ENROLL NOW @ UPGRAD

Leave a comment

Your email address will not be published.

×