JPMS Migration Playground
This tutorial presents a complex scenario of migrating a non-modular project to JPMS. Inspired by a scenario I previously faced where one of my transitive dependencies was in-accessible (and not required).
Scenario Walkthrough
Project bar is the missing artifact used by foo. It is configured to be deployed to foo's lib folder as a non-modular jar.
Project foo is the artifact we require in our project, baz. It is configured to be deployed to baz's lib folder as a non-modular jar.
To work around the obvious compliation error of trying to compile foo
when bar
is inaccessible, we used the flatten plugin to strip foo's pom from its dependencies so that bar will not be known at compile time to whoever uses foo.
Basically, baz depends on foo, without depending on bar and the code compiles successfully. π
It will, however, throw a NoClassDefFoundError
exception if we were to try an access bar's classes. This is demonstrated in BazTest.java.
Pre-JPMS code is in this commit.
JPMS: foo as Automatic Module
We can get foo
in our modulepath, implicitly making it an automatic module
by explicitly requiring it by its unstable name. π΅
Demonstrated in this commit.
Note that when compiling, the compiler will inform us of the automatic module
usage:
[INFO] Required filename-based automodules detected: [foo-0.0.1.jar]. Please don't publish this project to a public artifact repository!
This means our module won't be a pure module. And we won't be able to make the best out of JPMS
. Features like jlink
don't work with automatic modules
. π
Migrating foo
We use the moditect plugin to tweak foo
. However, in our case, we can't access bar
. Although our project, baz
, doesn't require it, it's required by foo
.
For clarification:
- Our project in the works is baz.
- The non-modular jar foo is given to us (without the source files).
- The non-modular jar bar is not given to us, nor do we require it.
We aim to make foo
modular while ignoring bar
so that baz
can truly leverage JPMS
features while requiring foo
.
We're using the junit-platform plugin for testing.
Create a module-info descriptor
The first step is to create a module-info
descriptor for foo
. This can be achieved in two ways.
From the command line (note the --ignore-missing-deps
because we don't have bar
):
jdeps --generate-module-info .\target\descs --ignore-missing-deps .\lib\com\example\foo\0.0.1\foo-0.0.1.jar
This will create .\target\descs\foo\module-info.java
:
module foo {
exports com.example.foo;
}
The same can also be achieved in build time using the moditect
plugin. Better yet, we can now give the module a stable name.
By convention, let's name it com.example.foo
:
<plugin>
<groupId>org.moditect</groupId>
<artifactId>moditect-maven-plugin</artifactId>
<version>1.0.0.RC1</version>
<executions>
<execution>
<id>generate-module-info</id>
<phase>initialize</phase>
<goals>
<goal>generate-module-info</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/descs</outputDirectory>
<modules>
<module>
<artifact>
<groupId>com.example</groupId>
<artifactId>foo</artifactId>
<version>0.0.1</version>
</artifact>
<moduleInfo>
<name>com.example.foo</name>
</moduleInfo>
</module>
</modules>
<jdepsExtraArgs>--ignore-missing-deps</jdepsExtraArgs>
</configuration>
</execution>
</executions>
</plugin>
Create a modular jar
Now that we have our module-info
descriptor ready, we can create a new modular jar with it.
This is easily achived with the moditect
plugin:
<plugin>
<groupId>org.moditect</groupId>
<artifactId>moditect-maven-plugin</artifactId>
<version>1.0.0.RC1</version>
<executions>
<execution>
<id>add-module-info</id>
<phase>initialize</phase>
<goals>
<goal>add-module-info</goal>
</goals>
<configuration>
<modules>
<module>
<artifact>
<groupId>com.example</groupId>
<artifactId>foo</artifactId>
</artifact>
<moduleInfoFile>${project.build.directory}/descs/com.example.foo/module-info.java</moduleInfoFile>
</module>
</modules>
</configuration>
</execution>
</executions>
</plugin>
This will create a modified version foo-0.0.1.jar
in target\modules
. The modified version will include the following module-info
descriptor and will qualify as a named module.
module com.example.foo {
exports com.example.foo;
}
Use the modular jar
To use our new modular jar, we update the requires
statement in the source files of the baz
project. From foo
, the automatic module
unstable name, to com.example.foo
, the named module
stable name.
// original using an automatic module
module com.example.baz {
requires foo;
}
// modified using the new named module
module com.example.baz {
requires com.example.foo;
}
A modification is also required in the test sources descriptor:
// original using an automatic module
open module com.example.baz {
requires foo;
}
// modified using the new named module
open module com.example.baz {
requires com.example.foo;
requires org.junit.jupiter.api;
}
Note that for the test descriptor, we needed to add a requires
directive for reading org.junit.jupiter.api
.
We didn't need to do so before because as an automatic module
, foo
could read all the other modules from the modulepath. So it bridged between the modules com.example.baz
and org.junit.jupiter.api
, so we didn't need to explicitly make com.example.baz
read org.junit.jupiter.api
.
Now that com.example.foo
is a named module
, com.example.baz
needs to explicitly require org.junit.jupiter.api
.
Failing to do so will result in a compilation error:
[ERROR] .../src/test/java/com/example/baz/BazTest.java:[3,32] package org.junit.jupiter.api is not visible
Add the new module to the Modulepath
This is where it gets tricky. Typically, we would configure the compiler to include the new module like so:
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<compilerArgs>
<arg>--upgrade-module-path</arg>
<arg>${project.build.directory}/modules</arg>
</compilerArgs>
</configuration>
</plugin>
This, unfortunately, will not work in our case. π
The original modulepath is constructed from the classpath, every monolithic jar is treated as part of the unnamed module
. This means our jar will exist twice on the modulepath, as part of the unnamed module
and as a named module
named com.example.foo
.
When trying to compile the test classes that access the module, we'll get the obvious error:
[ERROR] .../src/test/java/module-info.java:[1,6] module com.example.baz reads package com.example.foo from both com.example.foo and foo
To avoid the above error, we cannot do upgrade-module-path
. We must reconstruct the modulepath from scratch, excluding the original jar.
Create a new Classpath
First, we use the dependency plugin to create a temporary file with the classpath content excluding foo
in target\fixedClasspath.txt:
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>create-classpath-file</id>
<goals>
<goal>build-classpath</goal>
</goals>
<configuration>
<outputFile>${project.build.directory}/fixedClasspath.txt</outputFile>
<excludeArtifactIds>foo</excludeArtifactIds><!-- every aritifact recreated with moditect should be listed here -->
</configuration>
</execution>
</executions>
</plugin>
Create a new Modulepath
We then use the gmavenplus plugin to execute a small Groovy script creating a property containing the fixed modulepath.
We use the os plugin to create the os.detected.name
property.
<extension>
<groupId>kr.motd.maven</groupId>
<artifactId>os-maven-plugin</artifactId>
<version>1.6.2</version>
</extension>
And execute a Groovy script creating a property named modulePath
containing the content of the fixed classpath and the named module we previously created:
<plugin>
<groupId>org.codehaus.gmavenplus</groupId>
<artifactId>gmavenplus-plugin</artifactId>
<version>1.12.0</version>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-ant</artifactId>
<version>3.0.7</version>
<scope>runtime</scope>
</dependency>
</dependencies>
<executions>
<execution>
<phase>process-sources</phase>
<goals>
<goal>execute</goal>
</goals>
<configuration>
<scripts>
<script><![CDATA[
def delimiter = project.properties['os.detected.name'] == 'windows' ? ';' : ':'
def file = new File("$project.build.directory/fixedClasspath.txt")
project.properties.setProperty 'modulePath', file.text + delimiter + "$project.build.directory/modules"
]]></script>
</scripts>
</configuration>
</execution>
</executions>
</plugin>
Patch compiler with new Modulepah
As simple as:
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<compilerArgs>
<arg>--module-path</arg>
<arg>${modulePath}</arg>
</compilerArgs>
</configuration>
</plugin>
Patch testing Classpath
Next, we must exclude the original monolithic jar foo
and include the modular one on the test classpath. This can be achieved with junit-platform plugin tweaks:
<plugin>
<groupId>de.sormuras.junit</groupId>
<artifactId>junit-platform-maven-plugin</artifactId>
<version>1.1.0</version>
<extensions>true</extensions>
<configuration>
<executor>JAVA</executor>
<tweaks>
<additionalTestPathElements>
<element>${project.build.directory}/modules/foo-0.0.1.jar</element>
</additionalTestPathElements>
<dependencyExcludes>
<exclude>com.example:foo</exclude>
</dependencyExcludes>
</tweaks>
</configuration>
</plugin>
That's it.
Everything now compiles, and all the tests pass.
π
The key added value here is that both the project baz
and the local dependency foo
are now named modules
, although we are still missing bar
, of course.
We can also use moditect
to make foo
stop exposing packages related to bar
so we won't be able to access them by mistake.
π
I had fun playing around with JPMS
; I hope you did, too.
You can check out the code for this playground in Github.
Top comments (0)