Better integration of Java modules as dependencies in the future of Maven

[hendrikebbers]

This is based on the discussion in #11

We need to discuss how the Java module system can have a better integration in the Maven dependency definitions. Especially since maven dependecies and java modules have some common definitions but next to that some definitions that might nit work perfectlly well together.

Goal of this milestone should not be to have a final 100% solid integration in Maven but to have a definition for the future with a working prototype. Next to that parts of the prototype that does not make Maven 4 incompatible can be merged directly to Maven.

[desruisseaux]

There is one functionality that we may need to add in Maven core: the capability to get the JPMS name of a JAR dependency. It involves opening the JAR file and reading its module descriptor. Because many plugins may need this information, handling that in Maven core would allow to cache the JPMS module name after the first request.

[rmannibucau]

There is one functionality that we may need to add in Maven core

-> There is one functionality that we may need to add in Maven shared tools ? core don't care at all about all that stuff and it is not its responsability.
Ultimately it could be a maven plugin api service but my 2 cts is that it is very localised for a few tools (toolprovider) and not that generic so would fit very well a plugin shared lib too.
Does not prevent the caching in the maven session - agree it would be good to cache it.

[jjohannes]

Here is a breakdown of what (I think) should be done here.

Create a Maven Extension that adopts features from the similar Gradle plugin to Maven with the following features:

• (1) Building a multi-project (without publishing):
  • Parse the module-info.java file where present
  • Map each requires to a dependency
    • For Modules in other Maven submodules in the same build, the information should be determined from the project model
    • For 3d party dependency, the mapping properties file from the Gradle plugin can be reused
    • There should be an option to place additional mappings in a property file in the project
    • The scope should be mapped as good as possible (requires transitive -> compile, requires static -> provided)
  • Versions need to be added to 3rd party the dependencies (from <dependencyManagement> block of POM or parent POM or imported BOM). Ideally, the mechanism that merges the versions into dependencies defined in a POM can be reused.
• (2) Publishing a project
  • The dependencies should end up in the consumer POM, ideally the scope can be different in some cases: requires maps to compile in project POM, but to runtime in consumer POM
• (3) Dealing with conflicting modules (several modules with the same name)
  • List different kinds of conflicts that are typical in Java and document how to deal with them in Maven using existing mechanics such as exclude and profiles (to select between alternatives)
  • Write proposals for possible enhancements in <dependencyManagement> to improve detection and resolution of certain kinds of conflicts
• (4) Dealing with incomplete Jars
  • Show how Jars can be patched if module-info.class is missing. Use what is available in the ModiTect plugin.(https://github.com/moditect/moditect).
  • Write proposal of possible enhancements to the Jar patching mechanism
• (5) Testing
  • Show how Whtiebox and Balckbox testing is done. Use what is available in the ModiTect plugin.
  • Write proposal of possible enhancements for testing Java Modules.
• (6) Write a guide how to setup a Java Module System centered project with Maven.

In the end, this will show how a small, typical Java Module System centered project like https://github.com/gradlex-org/java-module-dependencies would look in this setup and how other use cases we have in a real project like https://github.com/hashgraph/hedera-services are solved (and provide a list of things that cannot be easily solved, if any).

[desruisseaux]

Can we split the work in two phases? First, allow JPMS support in projects having all the required module-info with no conflict. Then in a second phase, develop plugins for managing missing module-info and conflicts.

[rmannibucau]

While all the data stay in the pom and there is never any need to read both the moduleinfo and the consumer pom to get a valid model it sounds saner to split.

My 2cts would be that jpms is already supported (recall @sormuras explaining it) even if default is not always friendly but switching globally (does not make sense locally) the default is likely an issue for more people than the number it will help since, once again, it just works today.

Side note : 1 is promised to split the model and be bad for users, please dont do.

[cowwoc]

@rmannibucau What do you mean by split model? Do you mean that you prefer keeping all the information in pom.xml and ignoring the contents of module-info.java altogether?

[sormuras]

Mind that you (build tool) never generate missing module declarations for me: https://www.sitepoint.com/maven-cannot-generate-module-declaration/

[rmannibucau]

@cowwoc in a project it is mainly "your" (ie dev) choice to modelize the model as you want (with the bad IDE integration risk you accept to be very concrete) but on the consumer side the pom will stay the single source of data whatever you do by design. What we absolutely want to avoid is to load the jar to have the model, the consumer pom must stay the absolute single source (+ transitive pom-only).
Now in the project itself - where maven polyglot support is one way to impl module-info support - you are more free but as mentionned 1. justifies to 100% use the pom and then dispatch since module-info is not a dependency management but just a linking descriptor.

@desruisseaux just (almost) dropped the bad heuristic we had between classpath and module path, I don't think it is welcome to add yet another heuristic to map module name to jars (which would be as bad, take spec jars as an example or bundles vs granular deps).

A worse option would be a file mapping since you have the jar in the pom, if it is or not on the module path and the module path in the module-info and it is 100% sufficient, adding a file to do the mapping would create yet another maintenance cost for maven users and yet another source of ambiguity and error.

[desruisseaux]

@jjohannes is the property file really necessary? It seems to me that this information can be obtained automatically by reading the module descriptors of each dependency.

@rmannibucau : I propose the opposite of what you said: the ultimate source of true are the module-info.class files. The pom.xml files would be only complementary (version numbers and URL where to download). It would imply parsing the module descriptors of all dependencies listed in the <dependencyManagement> section. But I think that with this parsing, no property file will be needed.

[rmannibucau]

If there is no issue there will be no issue, now we already cases which will fail as mentionned.

Loading a compiled/compilable code is, for now, not an option by default.

All proposed solution are ok and doable in an extension but I dont see them hitting maven before a rebirth from scratch (likely a new project technically) cause user impacts are too high.

Lastly, Im not sure why it is the happy path since not the oracle recommended way...

My 2 cts will be that you can use mx if you want to do all the oracle way - still no idea which feature you are after since at the end you build your app for all cases frictionless today already - once type enhancement integration will be finished but it is planned.

[desruisseaux]

both have enough big cons to use module-info as source

@rmannibucau , this is not a choice. You can put anything you want in the POM file, no matter if the dependencies appear in the class-path or in the module-path, if a dependency is not in the module-info file (potentially indirectly), it will ignored by the JVM, period (unless there is --add-reads options). Even the class-path will not work, unless there is an --add-reads <module name>=ALL-UNNAMED option. Try it by yourself.

[rmannibucau]

This is not related to this topic, just configure the plugins as needed, but this is a runtime concern so a plugin conf by design and as shown, depends of the plugin, not the project.

[desruisseaux]

this is a runtime concern

No, this is a compile-time and a runtime issue. If your dependency is not in module-info and there is no --add-reads options, your code will not compile. This is not a plugin configuration issue. This is very core to how JPMS work.

[rmannibucau]

...the runtime for maven is its plugins so it is a runtime concern so a plugin concern as written...