On Sun, Oct 4, 2015 at 10:13 AM, Alan Bateman <alan.bate...@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
