What do I need to build JDK 9 project with non-modular dependencies using Maven

Siliarus :

I have a simple Java 9 SE project with one dependency on a non-modularized project (chose Weld SE for this example) and I am trying to build it with Maven (clean install).In order for Java 9 to kick in, I have added module-info.java. Originally, this file only contained module name and had no requires formulas.

Please bear in mind that my sole dependency is NOT a modular project, therefore I presumed Maven will put in the classpath (not module-path) and hence it will end up in the unnamed module as described in State of the modular system.

Now, my Maven version is 3.3.9 and I am aware that I need to use Maven compiler plugin in version 3.6, as described here Of course I have downloaded JDK 9 EA build with jigsaw and set Maven to use that.

If I build my project without module-info.java, everything works, stuff is added to classpath and build succeeds. I suppose Maven just sticks to the old ways as long as you leave out that file.

However building it with module-info.java tells me that the classes from my dependency cannot be found on the classpath. So I ran Maven in debug mode (with -X) and indeed - all jars are under module-path and classpath is empty. This effectively means that all my dependencies are transferred into automatic modules and I need to declare them in module-info.java.

Once I declare the automatic module requirements(link to projects's module-info), I am able to build it on JDK 9. But it is kind of messy - my only pom.xml dependecy is on weld-se-core, yet my module-info requires me to declare a lot more requirements for compilation to pass.

Here is a whole GitHub project where all this can be observed.

So my questions are:

  1. Can I tell Maven to put some artifacts on classpath if I know they are not modularized? So that I can avoid the automatic module and the need to declare them?
  2. If I stick with automatic module, can I tell Maven to somehow transitively allow anything my dependency needs to bring in? E.g. other parts of Weld, CDI API etc.
  3. What is the actual reason, why I need to state, that my project requires modules, which I do not use directly? E.g. weld.environment.common
Naman :

Including few of the recent updates, I would try and answer this.

UPDATE

  • Java 9 was released publically on 21.09.2017.
  • The minimum compatible version of maven-compiler-plugin in today's date is 3.7.0.

    As already shared by @Tunaki on how you can configure it to build compatible versions for both JDK 1.5 to 8 and JDK 9.

Assuming from the question and comments, you are already aware of automatic modules and placing all the module dependencies on the module path.

Can I tell Maven to put some artifacts on classpath if I know they are not modularized? So that I can avoid the automatic module and the need to declare them?

For artifacts specified in the maven pom <dependencies> and the ones which are as well not included in the module-info.java of the current module are ultimately left behind to be accessed from the classpath in form of an unnamed module.

If I stick with automatic module, can I tell Maven to somehow transitively allow anything my dependency needs to bring in? E.g. other parts of Weld, CDI API etc.

No, since the automatic modules do not consist of an explicitly declared module-info.java, there is no such way of defining requires transitive for any transitive dependency that might be required by the present module.

From one of my past experiences, any Maven transitive dependency as detailed in the dependency:tree that is needed at compile time by the module would have to be explicitly defined using requires in the module-info of the current project.

What is the actual reason, why I need to state, that my project requires modules, which I do not use directly? E.g. weld.environment.common**

  • You do not need to specify requires for modules that are not required at compile or runtime by your module.

  • In case there is a dependency that is not required at runtime but required at compile time by your project, you would need to make sure that you define such module using requires static in your declarations.

    I would have preferably practiced a similar approach at present as well, as stated in the answer to should I keep or remove declared dependencies that are also transitive dependencies?

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=452185&siteId=1