Converting plain JARs to Java modules

[Peter Kriens]

The issue is that maven problems are not caused because maven is bad or that pom authors are stupid. The reason is that the module-to-module dependency architecture in maven (and Jigsaw) is error prone ...

Kind regards,

	Peter Kriens

On 9 nov. 2011, at 11:20, Alan Bateman wrote:

> On 09/11/2011 08:51, Peter Kriens wrote:
>> I have seen Alan's demo of converting poms to Jigsaw modules on JavaOne. I recall that Alan had to fixup most of the poms manually to make this work for Jigsaw? Even after fixing them up, there was no link into the type system or were these dependencies verifiable, you still had to hope that the poms were correct.
>> 
>> The problem is that module dependencies, like poms, introduce an alternate namespace which is fully disconnected from the Java type system. This requires manual maintenance and opens a large space for errors that are impossible with package dependencies.
>> 
>> Package dependencies are directly connected the Java type system and therefore imports can be automatically calculated from the code, creating a chain of verification.
>> 
> There wasn't any manual editing of POMs. The demo was real in that it connected to the specified repository (I think we specified a URL to maven central) to locate the requested artifact, downloaded its POM and the POMs of all of the transitive dependencies, worked out what needed to be downloaded, generated a module-info.class for each one and then installed them as modules in the specified module library.
> 
> Converting artifacts from maven repositories to modules isn't without its issues . As I'm sure you know, POMs tend to specify specific versions of their dependencies which periodically results in conflicts. It's easy to find examples where an application ends up depending on several different versions of commons-io or log4j or other commonly used libraries. Maven has various "strategies" for resolving these, the default as I understand it, being where it chooses the "nearest declaration" (essentially the linear class path). Jigsaw detects these conflicts at install when generating the configuration for the application module and so installation of the application module (the module with the entry point) correctly fails. In the demo we did have a check box called "Resolve Conflicts" to resolve conflicts with the same strategy and I think I remarked a couple of times that installing modules in this manner would result in running with something that is unlikely to have been tested and highly unsuitable for installing into a module library that is used by other applications.
> 
> There are several other issues too. One annoying one is artifacts that contain classes in packages that are exported by JDK modules. Other issues included JAR files with duplicate entries, JAR files with classes that fail verification, and other garbage like this.
> 
> I think it's too early to say exactly how we will integrate with Maven repositories. There is clearly a need (and a requirement) to be able to download and install artifacts from maven repositories as if they were modules. It's easy to envisage updating "jmod add-repo" to allow a URL to a maven repository be specified but it needs a bit more thinking about some of the issues first.
> 
> As regards POMs that have incorrect dependency information then I think that needs consideration too. As was mentioned earlier in the thread then static analysis of the class files could help. It's not going to detect all issues, reflection usages, etc. Ultimately though one would hope that that once we have a Java Module System that the artifacts uploaded to these repositories will that module declarations.
> 
> -Alan.
> 
>