Skip to content

Java Module path support

Epic 49

The major task of this epic is to extend Maven (4) towards support for the Java Platform Module System (JPMS), based on two discussions

  • 11 (Better Java Module System support for Maven 4)\ Requires (better) general support for JPMS in Maven 4, e.g., for Module generation, packaging, linking, testing, etc.
  • 35 (Maven supports compilation and execution on the classpath or module path)\ More specifically requires JPMS support wrt. Compilation and Execution.
📌 NOTE: Focus on Maven 4
Though this epic should mostly address Maven 4 support, the Maven Support & Care team has decided to at least try to fix major JPMS problems in Maven 3. Additionally, it should not only cover Maven Core and its plugins, but also relevant third party plugins and extensions, e.g., [MojoHaus](https://www.mojohaus.org/) plugins.

Relevant components

The following components (currently) relate to JPMS. (Note: Incomplete list, for sure.)

📌 NOTE: ASF Maven Confluence Page on JPMS support
We maintain a current list of Maven components and their support status wrt. JPMS in the ASF Confluence: [Full JPMS Support — Current State](https://cwiki.apache.org/confluence/x/rwp3Fw)
  • Maven

  • maven-compiler-plugin\ Compiles Java source code with support for module-path and module descriptors.

    📌 NOTE

    Geomatys' fork contains POCs and PRs for Maven 4 (see its Wiki).

    * maven-jmod-plugin\ Creates JMOD files for packaging native code and other resources alongside Java modules. * maven-jlink-plugin\ Creates custom runtime images using the jlink tool for modular applications. * MojoHaus * exec-maven-plugin\ Executes Java programs and applications with support for both classpath and module-path execution.

Users Mailing List Discussions

As of 2025-10-08, there were no discussions so far about JPMS on the Users List.

Dev Mailing List Discussions

TBD: filter out from Dev List JPMS Search

Slack Discussions

TBD

Known issues

In the course of working on this epic, we detected or further investigated (and partly resolved) the following issues.

Unresolved Issues

TBD

Resolved Issues

  • MojoHaus Exec Plugin:
  • Issue 426 addresses a JPMS sample application which does not work (the exec plugin cannot load a service provider). We resolved this by PR 500, introducing a Multi-Release JAR to add proper module loading (for JDKs >= 9).

Potential Use-/Showcases

  • Issue 67 of m-JMOD-p (targeting Yet Another JNI-D2XX Interface Project, USB-Drivers)
  • Complex (integration) testing
  • Issue 372 for the MojoHaus Maven Flatten Plugin proposes an extension to provide a starting point for a respective (flattened) test POM to run JPMS based integration tests. Note that the Flatten Plugin is more relevant to Maven 3, but this is nevertheless an interesting use case for JPMS.

JPMS Samples and other information

Specifications

Glossary

🔥 CAUTION
The terminology presented here is a first proposal for clarification purposes within this Epic. Whether these terms will be adopted long-term and receive broader support from the Maven community remains to be seen.
  • Aggregator Project\ A Maven project whose sole purpose is to group and build multiple modules or subprojects.
  • JPMS Module\ A module defined by the Java Platform Module System introduced in Java 9. It specifies encapsulation and dependencies for Java code at runtime and compile time.
  • Maven Module\ A term used prior to Maven 4 to denote subprojects in a multi-module build. Each module is a separate Maven project with its own POM, built under a parent aggregator.
  • (Maven) Multi-Release\ A JAR format supporting multiple versions of class files targeting different Java runtime versions. Allows a single artifact to provide specialized code for multiple JVM versions.
  • Multi-JPMS-Module-Project\ A project (or subproject) providing multiple JPMS modules, in contrast to classic Maven (3) Multi-Module setups.
  • Multi-Module Setup\ A classic Maven project structure (prior to Maven 4) that contains multiple Maven modules built together. It uses an aggregator POM to aggregate and manage the build of all contained components. In Maven 4, this term should be avoided to prevent confusion with Java modules organized in a module source hierarchy. Preferred terms are "multi-project setup" (for Maven subprojects) or "Multi-JPMS-Module-Project" (for projects providing multiple JPMS modules).
  • Multi-Project Setup\ A Maven build unit containing one or more subprojects, typically managed under a parent aggregator project.
  • Project\ A Maven build unit defined by a POM file, representing either a single project or a parent of (Maven) modules or subprojects.
  • Single-Project Setup\ A Maven build containing only one project without any subprojects nor modules.
  • Subproject\ The preferred Maven 4 term, replacing module to denote a nested Maven project within a multi-project setup. Each subproject has its own POM and is referenced in the parent’s <subprojects> element.