How should a build/launch tool best make use of modules?

[Alan Bateman]

On 05/10/2015 09:45, Ron Pressler wrote:
> :
>
> Then let me rephrase the question :) The current practice for build 
> tools to solve the problem of transitive-dependency version conflicts 
> is via shadowing, which is hacky and brittle. Does the module system 
> offer other /means/ of solution (not a direct solution, of course)?
>
> After all, shadowing is a solution for the problem of dependency 
> hiding (or dependency encapsulation), which is something the module 
> system is intended to solve. Shouldn't it help with this problem? The 
> requirements document is a bit unclear on the issue; it delegates 
> version selection to build tools -- where it belongs -- and it 
> mentions that multiple versions are supported via dynamic 
> configuration which is intended for containers. The problem of 
> transitive-dependency version conflict is not discussed, except by 
> hinting that it may not be important enough, because "most 
> applications are not containers and, since they currently rely upon 
> the class path, do not require the ability to load multiple versions 
> of a module". That is not quite accurate. Most applications rely on 
> the classpath /plus/ shadowing. A GitHub search finds over 37K 
> /direct/ uses of shadowing 
> <https://github.com/search?l=maven-pom&p=1&q=maven-shade-plugin&type=Code&utf8=%E2%9C%93>, 
> and that is a very, very small part of the picture (even if many of 
> those results are projects don't really require it) because shadowing 
> is used by libraries to hide their dependencies, and those libraries 
> are then used by many more projects that don't use shadowing directly. 
> Any project that has even a single transitive dependency that makes 
> use of shadowing is facing the problem of version conflicts (and 
> handles it with this hack).
The proposed module system isn't providing a solution (or 
recommendations), it instead leaves it to the build/dependency 
management tools as you've already found.


>
> Which brings me to the second problem. The way module configurations 
> are arranged -- i.e. with a hierarchy of layers -- makes sense for 
> multi-application containers, but less sense for the problem of 
> dependency version conflict (as I explained in the example), unless 
> I'm missing something.
>
> It seems like the current design could be slightly enhanced to 
> accomodate both problems.
>
I don't think you are missing anything. Module layers are nice for 
contains that start multiple applications in the same VM that are using 
different versions of components. They also work well for components 
that support plugins.

All I can suggest is that feedback and suggestions on the design should 
to be sent to jpms-spec-comments.

-Alan.