Maven is a build tool that manages projects and dependencies. It aims to make the build process easy and provide a uniform system. With Java 9, Maven faces challenges due to the module system's differences from the classpath. Specifically, the modulepath does not support all file types like the classpath. This causes issues for Maven which relies on dependencies being on the classpath. Additionally, automatic modules generated from JAR files can cause problems for projects. Maven cannot directly generate module descriptors but tools like Jdeps can assist with initial descriptors. Overall, while challenges exist, Maven can still be used for most projects with Java 9.

1. APACHE MAVEN AND ITS
IMPACT ON JAVA 9
ROBERT SCHOLTE
CHAIRMAN APACHE MAVEN
@rfscholte

3. Maven
Java
< 8

4. Maven
Java
< 8Java 9

5. APACHE MAVEN
“Apache Maven is a software project management and comprehension tool. Based on the concept of a
project object model (POM), Maven can manage a project's build, reporting and documentation from a
central piece of information.”

6. MAVEN’S OBJECTIVES
Maven’s primary goal is to allow a developer to comprehend the complete state of a development effort in
the shortest period of time. In order to attain this goal there are several areas of concern that Maven
attempts to deal with:
• Making the build process easy
• Providing a uniform build system
• Providing quality project information
• Providing guidelines for best practices development
• Allowing transparent migration to new features

7. PURPOSE POM.XML
• Build instructions
• Dependency references (scope controls usage)
• Reporting
• Project information

8. IT’S ALL ABOUT
THE CLASSPATHS
…

9. THE MODULEPATH MISMATCH
• Output directories
• Jar files
• Zip files (not supported by Maven)
Classpath accepts:
• Output directories
• Modular output directories
• Directory with jars
Original modulepath accepts:

10. <dependency>
<groupId/>
<artifactId/>
<version/>
<type/> <!-- defaults to jar -->
<classifier/> <!-- optional -->
</dependency>
/groupId*/artifactId/version/artifactId-version(-classifier).type

11. … WHEN USING THE MODULEPATH …
• Point to directory containing the jar (and more) ?
• Create lib directory with symbolic links to files ?
• Create lib directory and copy all files

12. THE MODULEPATH MISMATCH
Output
directories
Modular
output
directories
Directory with
jars
Jar files

13. ”
“As a final special case, if <module> is ALL-MODULE-PATH then all
observable modules found on the relevant module paths are added
to the root set. ALL-MODULE-PATH is valid at both compile time and
run time. This is provided for use by build tools such as Maven,
which already ensure that all modules on the module path are
needed. It is also a convenient means to add automatic modules to
the root set.
--add-modules <module>(,<module>)*

14. MODULE NAMES

15. DEJA VU
• What is the proper module name?
• What is the proper groupId and artifactId?

16. ”
“ Module names must be
as unique as the coordinates of dependencies
• Modulenames with numbers
• Automatic module names

17. MODULENAMES WITH NUMBERS
Project/product names
•AWS-EC2
•AWS-Route53
•AWS-S3
•C3P0
•DB2
•Fabric8
•H2
•JSRnnn
•OAuth2
Versioned libraries (includes
versioned packages)
•Commons-lang2
•Commons-lang3
Bridge libraries to different versions
•Jspc-compiler-tomcatN
•Mockwire-springN
•Surefire-junitN
Close to 30.000 groupId/artifactId end with a number (Central, March 2017)

18. #VERSIONSINMODULENAMES
Some have argued that library maintainers will be
tempted to encode major version numbers, or even
full version numbers, in module names. Is there
some way we can guide people away from doing
that?
Resolution Abandon the previous proposal to
mandate that module names appearing in source-
form module declarations must both start and end
with “Java letters”. Revise the automatic-module
naming algorithm to allow digits at the end of
module names.

19. AUTOMATIC MODULE NAMES
“The module name is otherwise derived from the name of the JAR file.”

20. NPM JAVASCRIPT PACKAGE
REGISTRY

21. EVIDENCE (OCT 2016)
Over 13500 entries

22. Jigsaw
Automatic modules are required for top-down
adoption
Maven
References to automatic module names will cause
collisions sooner or later
Library builders should never refer to automatic modules* and deploy to a public repository.
Application builders can choose to refer to automatic modules.
* Filename based

23. Application
Module descriptor without exports
maven-compiler-plugin logs info message in case of
automatic module usage
Library
Module descriptor with exports
Tip: Use Maven 3.5.0+ for colour support
maven-compiler-plugin logs WARNING message
in case of automatic module usage

24. AUTOMATIC MODULES
Ease of top-down migration for application builders
But what about “in the middle” library builders?

25. CONFERENCE EXAMPLE
Application my-app
Libraries jackson-core jackson-databind
jackson-
annotations
my-lib
java.base

26. MORE REALWORLD EXAMPLE
Application my-app
Libraries (direct deps) … … … my-lib
Libraries (transitive deps)
…
… … …
Libraries (independent deps) jackson-core jackson-databind jackson-annotations
java.base

27. 1library-a-1.0.jar

28. 2library-b-1.0.jar
module org.lib.b
{
requires library.a; // from filename
}

29. 3library-a-2.0.jar
module com.lib.a
{
}

30. 4library-c-1.0.jar
module org.lib.c
{
requires com.lib.a; // from descriptor
}

31. 5app-d-1.0.jar
module org.app.d
{
requires com.lib.b;
requires com.lib.c;
}

32. <project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.company.d</groupId>
<artifactId>app-d</artifactId>
<version>1.0.0-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>org.organization.b</groupId>
<artifactId>lib-b</artifactId>
<version>1.0</version>
</dependency>
<dependency>
<groupId>org.foundation.c</groupId>
<artifactId>lib-c</artifactId>
<version>1.0</version>
</dependency>
</dependencies>
</project>

33. app-d.jar (org.app.d)
requires com.lib.b;
requires com.lib.c;
library-b-1.0.jar (org.lib.b)
requires library.a;
library-c-1.0.jar (org.lib.c)
requires com.lib.a;

34. app-d.jar (org.app.d)
requires com.lib.b;
requires com.lib.c;
library-b-1.0.jar (org.lib.b)
requires library.a;
library-a-1.0.jar
(library.a)
library-c-1.0.jar (org.lib.c)
requires com.lib.a;
library-a-2.0.jar
(com.lib.a)

35. app-d.jar (org.app.d)
requires com.lib.b;
requires com.lib.c;
library-b-1.0.jar (org.lib.b)
requires library.a;
library-a-1.0.jar
(library.a)
library-c-1.0.jar (org.lib.c)
requires com.lib.a;
library-a-2.0.jar
(com.lib.a)

36. <project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.company.d</groupId>
<artifactId>app-d</artifactId>
<version>1.0.0-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>org.foundation.c</groupId>
<artifactId>lib-c</artifactId>
<version>1.0</version>
</dependency>
<dependency>
<groupId>org.organization.b</groupId>
<artifactId>lib-b</artifactId>
<version>1.0</version>
</dependency>
</dependencies>
</project>

37. app-d.jar (org.app.d)
requires com.lib.b;
requires com.lib.c;
library-c-1.0.jar (org.lib.c)
requires com.lib.a;
library-a-2.0.jar
(com.lib.a)
library-b-1.0.jar (org.lib.b)
requires library.a;
library-a-1.0.jar
(library.a)

38. app-d.jar (org.app.d)
requires com.lib.b;
requires com.lib.c;
library-c-1.0.jar (org.lib.c)
requires com.lib.a;
library-a-2.0.jar
(com.lib.a)
library-b-1.0.jar (org.lib.b)
requires library.a;
library-a-1.0.jar
(library.a)

39. MIGRATE
META-INF/MANIFEST.MF
•Automatic-Module-Name

40. 2library-b-1.0.jar
META-INF/MANIFEST.MF
Automatic-Module-Name: org.lib.b

41. POINT OF
NO RETURN
“If you refer to
dependency X:N as a
module and
dependency X:N-1 has
no module name, then
you cannot downgrade
dependency X
anymore”

42. STRONG ADVICES
- Project must be Java 9 ready!!
- No split packages
- No root classes
- For libraries that depends on at least one filename based automodule:
- Help depending projects by providing intended module name via MANIFEST
- Pick your modulename with care, e.g. the shared package

43. MISTAKES WILL HAPPEN
In fact, first invalid modules are already available at Maven Central
• asm-6.0_BETA ( org.ow2.asm)
• asm-all-6.0_BETA (org.ow2.asm.all) 1
• asm-debug-all-6.0_BETA (org.ow2.asm.debug.all) 1
Application developer cannot fix these mistakes (dependency-exclude doesn’t work)
1 Fixed with asm-6.0 by dropping *-all artifacts (asm includes debug information by default)
Same packages must
have the same
modulename
(otherwise potential
split package issue)

44. TIPS FOR USING JAVA 9 WITH MAVEN
• DON’T change your folder structure (no need for extra folder with module name)
• Modulepath or classpath? No change to dependencies: Plexus-java can help plugins to build up the path

45. PLUGINS REQUIRING JAVA.SE.EE (OR RELATED)
• MAVEN_OPTS = --add-module java.se.ee
• Maven must always run with Java 9
• All projects now use this extra module
• .mvn/jvm.config (--add-module java.se.ee )
• Per Maven project
• This project must run with Java 9
• JDK_JAVA_OPTION=“--add-module java.se.ee”
• Every Java 9 runtime will use this setting
Most plugins use same runtime as Maven ( versus forked runtime)

46. 1) Stackoverflow
2) Apache Maven mailinglists
3) Apache Maven Jira in case of bugs / improvements

47. SOURCE / TARGET 1.9
<release>9<release>
source/target < 1.8 : animal-sniffer

48. QUESTIONS?

49. CAN EVERY PROJECT BECOME MODULAR?
NO
- Java 9 is a gamechanger, it introduces new rules
- The older the project, the more likely it can’t follow these rules
- No worries, the classpath is still there and will stay!

50. THE BOOMERANG QUESTION
Or “the ever returning Maven/Java9/Conference question”
Will Maven generate the module descriptor?

51. NO
• Different purpose
• Pom is used to download jars and make them available
• Module descriptor is used to specify required modules
• Not all modules are dependencies ( e.g. java.logging, jdk.compiler )
• Module descriptor elements not covered:
• Module name
• Open module
• Exported packages
• Uses / provides services
• Pom 4.0.0 has no space for new elements

52. …BUT JDEPS CAN DO IT, RIGHT?
• Can create a rough module descriptor
• Intended to help with an initial descriptor
• Uses binary classes, i.e. AFTER compile-phase

53. POM HYGIENE
• dependency:analyse
• Analyzes the dependencies of this project and determines which are:
• used and declared (good)
• used and undeclared (via transitive dependency)
• unused and declared
Dependencies can be excluded,
required modules cannot

54. OTHER QUESTIONS?

55. THANK YOU
ROBERT SCHOLTE
Apache Maven BOF
Tuesday 19.45 – 20.30 Moscone West 2007
Brian Fox, Manfred Moser, Robert Scholte