On 02/03/2017 09:40 AM, Alan Bateman wrote:
On 03/02/2017 11:44, Robert Scholte wrote:Hi Nicolai, let's consider that my project depends on the following dependencies: com.foo.bar:library:1.0 and com.acme:library:2.3.1, both unnamed. I somehow want to have them both as requirements: module M.N { requires static library; // com.foo.bar:library requires library; // com.acme:library } How can I define that the 'requires static library' should be mapped to com.foo.bar:library:1.0 on the modulepath, while 'requires library' should be mapped to com.acme:library:2.3.1 One ugly solution would be: requires static library containing com.foo.bar.baz.SomeClass; requires library containing acme.AnotherClass; We should really wonder if ease-of-transition is worth the minefield we're creating with the introduction of automodules. IMHO all options we're trying to add to keep automodules will only over-complicate things, not even being sure if all edges are covered.I think automatic modules are critical to migration, otherwise things move at the pace of the slowest project (which might be 0km/h in case of unmaintained projects). A lot of the discussion here has been on the naming but automatic modules but the other important benefit of automatic modules is that they support bridging to the class path.
I still believe this conclusion is based on a false assumption, or rather a pair of them: the assumption that users will generally wish to distribute a module as a direct artifact of their build in any cases but the most proprietary, and the assumption that modularizing a project is something that is done when that project is compiled rather than when it is distributed. All evidence seems to indicate that these assumptions are completely unfounded.
Using tooling to migrate to a modularized environment is not only a perfectly reasonable alternative, but is very, *very* likely to be quite close to the standard build/distribute workflow coming out the gate and onward for many years. Maven and Gradle essentially dominate the world of Java project building. They (and their supporting utilities) already take on most if not all distribution tasks: customizing MANIFEST.MF and service files, bundling local and even remote resources, source and bytecode translation, annotation processing, customized packaging, etc. It seems inevitable that such tools will also be used build module distributions, performing resolution and wiring tasks on large groups of artifacts at a time and producing a module set or even an image at output, as a final step before CI and/or distribution. I cannot conceive of any other sane workflow unless as I said your environment is highly proprietary (neither consuming nor producing artifacts that are ever shared with anyone else nor shared across distibution-wide versions) and/or highly constrained (to a very small number of modules or using very rigid (and probably brittle) rules for artifact sharing). Note that in these cases, most if not all of the value proposition of modularity is already lost.
As regards the example naming clash then these two projects might already get complaints over their poor choice of artifacts, esp. when artifacts for both projects are in same directory (say where someone distributes with all JAR files in a `lib` directory).
-- - DML
