That README is such a gem Ralph! Thanks for documenting all that suffering. (README says Log4j 2 supports JPMS, shouldn't it rather be Log4j 3?)
There are actually pretty few modules whose test JARs are used by the downstream, mostly by log4j-perf. Could it be a viable option to move the benchmarks in log4j-perf to their associated modules (under src/perf?) and/or convert tests that produce test JARs into separate Maven modules, e.g., log4j-core-test, log4j-layout-template-json-test? With my pretty limited understanding of JPMS, I have the impression that this might ease the build pain to a certain extent. On Sat, Jun 19, 2021 at 12:53 AM Ralph Goers <ralph.go...@dslextreme.com> wrote: > > > > On Jun 18, 2021, at 2:19 PM, Jochen Wiedmann <jochen.wiedm...@gmail.com> > wrote: > > > > On Fri, Jun 18, 2021 at 6:20 PM Ralph Goers <ralph.go...@dslextreme.com> > wrote: > > > >> 2. The configuration does “strange things” because Maven doesn’t > support creating a > >> JPMS module, JPMS test module, and running unit tests in a single Maven > module > >> out of the box while also avoiding > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8265826. > >> The “strange configuration” makes that work. Log4j-Plugins is even more > “strange” > >> because in addition to the above it also has to compile the annotation > processor > >> without the module-info.java prior to doing the “build compile” so that > the annotation > >> processor exists. > > > > Are there existing Maven issues, that I could have a look at? Or, is > > the problem reproducible with a relatively simple example? > > I haven’t created any Maven issues for this because Maven is working as > designed, for the > most part. I did create > https://issues.apache.org/jira/browse/MCOMPILER-461 but that is > for a different problem I encountered. > > For the JPMS compiler bug I created > https://github.com/rgoers/jpms-compile-fails. That > bug was fixed in Java 17 so if we upgrade I could fix some of the > “strangeness”. I have not > tested with Java 17 to see if that also somehow fixes MCOMPILER-461. > > But to create a sample project just use the standard Maven Archetype to > create a project. > Then convert it to JPMS modules - you will need a module-info.java for > both the main > source and for the unit tests but the unit tests will “open” the main > module and all the test > classes will be in the same package space as the main source as is typical > for normal testing. > > Next create some classes that are used both in your unit tests and will be > used in downstream > tests. This is where it gets ugly. These tests have to be packaged in > their own jar and cannot > use the same package space as the main source, so typically you just would > add .test to > whatever the main source package is and put all these classes under that. > You will find that > you need to compile these separately from the other test classes and use a > module-info.java > that names the module properly. Once you have compiled these you would > then package them > as the test jar for the project. Once you do that you have to delete the > module-info.class file that > was generated and then compile the rest of the test classes with their > module-info.java file. > > As you can see, the complication is that JPMS doesn’t let you just package > all your test crap in > a jar and send it downstream for other modules to use as is typically done > without it. If you do > that you will get an error because it duplicates the main source modules > packages. > > Unfortunately, the test jar can’t be built in a separate module from the > main source because > it has dependencies on the main source and the test classes use the > classes in the test jar. > > So the problem really is that JPMS has made it so that any time you need > to package a test > jar you are going to have to do all this crap. Maven simply doesn’t have a > convention to > handle this. The fact that I also encountered a bug in the compiler just > made things worse > as that required that the module-info.java be compiled after all the > classes were compiled. > > https://github.com/apache/logging-log4j2/blob/master/log4j-core/README.md > pretty much > documents why I had to resort to all the messiness. > > Ralph > > >
