FWIW, I am still torn on whether log4j-core should have a module name of org.apache.logging.log4j.core or org.apache.logging.log4j.impl. If it is the second then log4j-api could restrict exporting packages only meant for the implementation to that module. That would require some refactoring of the API classes but that shouldn’t be too big of a deal. Is the benefit of doing that greater than the (hypothetical) benefit of supporting multiple log4j implementations at the same time? Should log4j-to-slf4j also then use the same module name since it replaces log4j-core?
Ralph > On Oct 14, 2017, at 10:40 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > I have committed the code for LOG4J2-2056. Log4j-api is a “real” module and > has a module-info.java while all the rest that can be modularized are > automatic modules. Please review and test. > > In order to create the module-info.java I had to do a few strange things: > Module-info.java is in the log4j-api-java9 project since log4j-api isn’t > compiled with Java 9. > Compiling module-info.java requires that the packages being exported exist > and have at least one class in them, so I had to create the directories and > place a dummy java class in them. > The assembly that creates the log4j-api-java9 zip ignores all the dummy files > and directories and only copies module-info.java and the two utility classes > into the zip. > > I have tested this with a simple program that only uses a module path but I > would appreciate more extensive tests before it is released. > > Ralph
