Yes. My main jar has org.apache.logging.log4j.core and the test jar has org.apache.logging.log4j.core.test. Although IntelliJ is very confused by what I am doing it has no part in this. I only build using maven from the command line. Yes, to get all these compiles to work I have had to move things to odd lifecycle phases, but that isn’t causing any problems. My plan was to build the test jar first and then build the unit tests into the same directories. The module-info.class for the unit tests should replace the module-info.class the test jar generated. However you now have me thinking it needs to be deleted as maybe that is what is causing the compiler to use a module path.
Ralph > On Apr 25, 2021, at 2:46 AM, Tibor Digana <[email protected]> wrote: > > You must have different Java packages in Jar modules in order to have > regular JMPS modules. > One user of Maven reported a bug against IntelliJ IDEA that the IDE does > not understand src/test/java/module-info.java. > The only way on how to support one common Java package and two JPMS modules > too is to bundle src/target/classes and src/target/test-classes and merge > both module-info.class, but it is against the idea of Maven lifecycle and > it may be erroneous. > T > >> On Sun, Apr 25, 2021 at 8:47 AM Ralph Goers <[email protected]> >> wrote: >> >> I am trying to convert Log4j 2 to be fully modularized and am running into >> problems with Log4j-core. First, I have hit a couple of nasty bugs when >> compiling >> on MacOS that are reflected in >> https://issues.apache.org/jira/browse/MCOMPILER-461 < >> https://issues.apache.org/jira/browse/MCOMPILER-461> and >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8265826 < >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8265826>. >> Basically the compiler seems to be converting directory names that have a >> class with the same name in the same package to upper case. >> >> To combat this I am forced to compile without a module-info.java during >> annotation processing and again with the module-info.java. >> >> To make matters worse, the log4j-api, log4j-plugins, and log4j-core >> modules all have test classes that need to be made available to downstream >> modules for >> testing. Prior to JPMS we just passed the test jars on, but since many of >> the unit tests need to use the same packages as the main source the test >> modules to be >> passed on had to be placed into their own “test” package and so had to be >> moved out from the rest of the unit test classes so they could be package >> in a valid >> module. >> >> As a result of this I had to convert my directory structure into >> src/main/java/ main classes >> src/main/java9/module-info.java >> src/test/java/ unit test classes & module-info.java >> src/test/java-test. Shared test classes >> src/test/java-test9/module-info.java >> >> and my build consists of: >> 1. Running Log4j’s annotation processor against the main classes without >> module-info.java. >> 2. Compiling Log4j’s main classes with module-info.java. >> 3. Compiling the separate test classes with its module-info.java. >> 4. Packaging these test classes into the tests jar. >> 5. Running Log4j’s annotation processor against the unit test classes. >> 6. Compiling the unit tests. >> >> But the build fails at step 5. If I do not include a module-info.java in >> the unit tests I get failures due to milling modules because maven is >> setting the module >> path (presumably because the main classes have one). If I do include the >> module-info.java then I run into the reported bugs and the compile fails >> with >> duplicate class errors. I’ve thought of trying to compile without >> module-info.java but I have to create a valid JPMS module for the separate >> test classes so that >> has to be done before starting on the unit tests. >> >> The only way I can see to do this is to run the annotation processor >> without the module path but it seems the compiler plugin provides no option >> to do that. >> >> My next thought is to try using >> https://github.com/bsorrentino/maven-annotation-plugin < >> https://github.com/bsorrentino/maven-annotation-plugin> to perform the >> annotation processing and see if I have better luck. >> >> I should also add that these projects look like hell in Intellij as it has >> no idea how to resolve the second test directory. >> >> Does anyone have any thoughts on how this could be more easily >> accomplished? I can’t imagine I am the only person who needs to create a >> valid test jar. >> >> Ralph --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
