Thanks Christian. I’ve read that blog several times. It helped me immensely in getting anything to work. However, it doesn’t exactly cover my situation where some of the test classes need to be packaged into their own module for downstream maven modules. That, and the Javac bug on MacOS are what is creating all this difficulty.
Ralph > On Apr 25, 2021, at 7:40 AM, Christian Stein <[email protected]> wrote: > > Robert refers to > https://sormuras.github.io/blog/2018-09-11-testing-in-the-modular-world > > Caveat: I didn't look in detail into current Maven's core plugins, like the > compiler plugin > and/or Surefire/Failsafe. So, things might have changed compared to what I > wrote back > in 2018. > > > >> On Sun, Apr 25, 2021 at 4:33 PM Apache <[email protected]> wrote: >> >> Robert, I am not sure what you are getting at with reference to black box >> and white box testing. I am simply trying to figure out how to get a >> buildable project. >> >> Ralph >> >>> On Apr 25, 2021, at 1:40 AM, Robert Scholte <[email protected]> >> wrote: >>> >>> I think you need to talk with Christian Stein about blackbox and >> whitebox testing. >>> >>> Robert >>>> On 25-4-2021 08:47:20, 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 and >> 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 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] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
