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.
