You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Olivier Lamy <ol...@apache.org> on 2022/10/17 10:33:07 UTC
Re: Modular path vs. class path determination
On Sat, 1 Oct 2022 at 01:22, Ceki Gülcü <ce...@qos.ch> wrote:
>
>
> Hello all,
>
> The logback is attempting to migrate to Junit 5. As a consequence of
> this migration, a handful of tests that were previously successful, now
> fail.
>
> For example, the ch.qos.logback.classic.net.DilutedSMTPAppenderTest
> recently failed with the following error:
>
> java.lang.NoClassDefFoundError: jakarta/mail/internet/AddressException
>
> During surefire execution, the j.m.i.AddressException class is not
> found. It is part of jakarta-mail.jar. I believe this artifact is on the
> module path but somehow is not resolved.
>
> Anyway, upgrading org.assertj:assertj-core from l.7.1 to 3.23.1 seems to
> help. Don't ask me why...
>
> I am also puzzled by the fact that many JMPS modularized artifacts are
> placed on the class path instead of the module path when the tests are run.
well maybe the problem is some are on module path and some others on
the class path..
when migrating the Jetty project from surefire M5 to M7 I had a lot of
jpms issues because some logic changed especially in this part.
I wanted to have some opinions on what sort of configurations we could
add but this didn't get much attention :)
(https://issues.apache.org/jira/browse/SUREFIRE-2097)
Maybe nobody really cares of jpms...
>
> Anyway, I think I may have stumbled upon a bug in Maven or the surefire
> plugin. Indeed, when I run mvn install from within the logback-classic
> module, the DilutedSMTPAppenderTest mentioned above succeeds.
>
> However, when I run it as
>
> mvn install -Dtest=ch.qos.logback.classic.net.DilutedSMTPAppenderTest
>
> the test fails with the following exception
>
> [ERROR]
> ch.qos.logback.classic.net.DilutedSMTPAppenderTest.testTriggeringPolicy
> Time elapsed: 0.001 s <<< ERROR!
> java.lang.NoClassDefFoundError: jakarta/mail/internet/AddressException
> at
> ch.qos.logback.classic@1.4.2-SNAPSHOT/ch.qos.logback.classic.net.DilutedSMTPAppenderTest.setUp(DilutedSMTPAppenderTest.java:41)
> at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>
> [cut]...
> Caused by: java.lang.ClassNotFoundException:
> jakarta.mail.internet.AddressException
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> ... 74 more
>
>
> Comparing the command line of the two executions, the 'mvn install'
> execution has jakarta-mail-api on the module-path, whereas the 'mvn test
> -D=..." has jakarta-mail-api on the class-path.
>
> If you wish to confirm this, I have created tag 'possible_mvn_issue'
> in the logback repository on github .
>
> https://github.com/qos-ch/logback/releases/tag/possible_mvn_issue
>
> Let me know if this merits the creation of a Jira issue.
>
> Your feedback would be most appreciated.
>
> --
> Ceki Gülcü
>
> Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Modular path vs. class path determination
Posted by Ceki Gülcü <ce...@qos.ch>.
Hello Martin, Olivier,
Since I posted on this thread, I have abandoned the idea of integration
testing in the same Maven module. Instead, for module X, white-box
testing is still done within X/src/test/ and integration testing done in
a new and separate module X-blackbox which is also Jigsaw/JPMS modular.
This approach is a lot less painful than in-single-module testing.
--
Ceki Gülcü
Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch
On 10/17/2022 1:27 PM, Martin Desruisseaux wrote:
> Le 17/10/2022 à 12:33, Olivier Lamy a écrit :
>
>> I wanted to have some opinions on what sort of configurations we could
>> add but this didn't get much attention :)
>> (https://issues.apache.org/jira/browse/SUREFIRE-2097) Maybe nobody
>> really cares of jpms...
>>
> On my side I do care a lot about JPMS. But I got the feeling that Maven
> model is not well suited to JPMS, which caused me to stop following JPMS
> issues on Maven and look for other build solution.
>
> The difficulty I have with JPMS in Maven is that I would like to break
> the "one Maven module = one JPMS module" relationship. Instead I would
> like "one Maven module = one compilation unit", i.e. a single call to
> javac, javadoc or other java tools, which may itself comprise many JPMS
> module.
>
> Martin
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Modular path vs. class path determination
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Le 17/10/2022 à 12:33, Olivier Lamy a écrit :
> I wanted to have some opinions on what sort of configurations we could
> add but this didn't get much attention :)
> (https://issues.apache.org/jira/browse/SUREFIRE-2097) Maybe nobody
> really cares of jpms...
>
On my side I do care a lot about JPMS. But I got the feeling that Maven
model is not well suited to JPMS, which caused me to stop following JPMS
issues on Maven and look for other build solution.
The difficulty I have with JPMS in Maven is that I would like to break
the "one Maven module = one JPMS module" relationship. Instead I would
like "one Maven module = one compilation unit", i.e. a single call to
javac, javadoc or other java tools, which may itself comprise many JPMS
module.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org