> 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
