You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Ralph Goers <ra...@dslextreme.com> on 2021/04/25 06:46:57 UTC
JPMS compile problems
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
Re: JPMS compile problems
Posted by Apache <ra...@dslextreme.com>.
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 <ti...@apache.org> 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 <ra...@dslextreme.com>
>> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: JPMS compile problems
Posted by Tibor Digana <ti...@apache.org>.
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 <ra...@dslextreme.com>
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
Re: JPMS compile problems
Posted by Ralph Goers <ra...@dslextreme.com>.
Thanks Christian,
Thanks to either a good night’s sleep or reading the messages in this thread I realized deleting the module-info.class
file generated to create the test jar might fix the problem. It did. After deleting it the compiler only used the class path
to run the annotation processor and it finally worked.
I am definitely going to have to blog about this ordeal when I finally get it working. I am really not sure modularization
is really worth all the effort.
While Bach looks interesting I don’t want to replace Maven. To me it makes more sense to have a single Maven plugin
that compiles and packages the JMPS module in one step. Then the process would look like:
1. Build and package the main module source (i.e. compile, create source and binary jars).
2. Build and package the test module source - then delete the generated module-info.class.
3. Compile the unit test source.
4. Run the unit tests.
5. Install/Deploy the created jars.
Doing it by invoking all the usual plugins one at time is definitely creating a convoluted build., so having a plugin to
deal with this would definitely help.
Ralph
> On Apr 25, 2021, at 8:04 AM, Christian Stein <so...@gmail.com> wrote:
>
> On Sun, Apr 25, 2021 at 4:53 PM Apache <ra...@dslextreme.com> wrote:
>
>> Thanks Christian. I’ve read that blog several times. It helped me
>> immensely in getting anything to work.
>
>
> You're welcome and glad to hear that it helped you!
>
>
>> 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.
>
>
> Yeah. That's one reason I decided for Bach [0] that "javac + jar" is an
> atomic action. And that goes for sources of main and test scope. That
> simplifies a lot of cases, not only when testing in the modular world
> (adding main/test MRJARs to the mix is easy here, for example).
>
> IIRC, using the Maven-Invoker-Plugin (or Maven-Exec-Plugin) with
> hand-crafted mvn (java) calls was always a way to get things working again.
> At least, as a last resort.
>
> [0]: https://github.com/sormuras/bach
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: JPMS compile problems
Posted by Christian Stein <so...@gmail.com>.
On Sun, Apr 25, 2021 at 4:53 PM Apache <ra...@dslextreme.com> wrote:
> Thanks Christian. I’ve read that blog several times. It helped me
> immensely in getting anything to work.
You're welcome and glad to hear that it helped you!
> 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.
Yeah. That's one reason I decided for Bach [0] that "javac + jar" is an
atomic action. And that goes for sources of main and test scope. That
simplifies a lot of cases, not only when testing in the modular world
(adding main/test MRJARs to the mix is easy here, for example).
IIRC, using the Maven-Invoker-Plugin (or Maven-Exec-Plugin) with
hand-crafted mvn (java) calls was always a way to get things working again.
At least, as a last resort.
[0]: https://github.com/sormuras/bach
Re: JPMS compile problems
Posted by Apache <ra...@dslextreme.com>.
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 <so...@gmail.com> 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 <ra...@dslextreme.com> 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 <rf...@apache.org>
>> 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 <ra...@dslextreme.com> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: JPMS compile problems
Posted by Christian Stein <so...@gmail.com>.
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 <ra...@dslextreme.com> 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 <rf...@apache.org>
> 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 <ra...@dslextreme.com> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: JPMS compile problems
Posted by Apache <ra...@dslextreme.com>.
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 <rf...@apache.org> 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 <ra...@dslextreme.com> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: JPMS compile problems
Posted by Robert Scholte <rf...@apache.org>.
I think you need to talk with Christian Stein about blackbox and whitebox testing.
Robert
On 25-4-2021 08:47:20, Ralph Goers <ra...@dslextreme.com> 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