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

[Ron Pressler]

On Sun, Oct 4, 2015 at 10:13 AM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:
>
> The module system isn't suggesting any solutions, it is instead leaving
> this problem to the build tools and containers.
>
>
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).


> Starting an application in its own layer should be fine, it might even use
> a different version of a module that the container (=agent in this case) is
> using. Multiple layers are fine too.
>
>
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.

Ron