[
https://issues.apache.org/jira/browse/SUREFIRE-1543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16556299#comment-16556299
]
Michał Zegan commented on SUREFIRE-1543:
----------------------------------------
It lies on my private gerrit. It should be accessible as
[https://git.webczatnet.pl/ssh4j.git|http://git.webczatnet.pl/ssh4j.git] (the
submodule ssh4j-core).
However, I also found the cause of the problem. It seems that JAXB-api version
2.3.0 *explicitly* checks, if the jaxb implementation module is named, and if
not, just ignores it (as in, it uses it but does not call addOpens to open the
model package to it), causing the error seen in logs.
So, there is the proof that adding those things to classpath may change test
results. To fix this I would either have to open package unconditionally (bad),
or use --add-opens to open this package to all unnamed (bad). if surefire would
do the latter itself it would also be bad for the reasons outlined in the bug
description, unless jaxb impl modules would not be put in classpath.
One thing I am wondering about... Not sure if stuff like mockito need deep
reflection capabilities and calling inaccessible members, and you rather do not
want to open module packages to test only dependencies, so what would you do...
> running tests when application is a java9 module seems to be broken
> -------------------------------------------------------------------
>
> Key: SUREFIRE-1543
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1543
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
> Affects Versions: 2.22.0
> Reporter: Michał Zegan
> Priority: Major
> Attachments: 2018-07-25T23-04-55_763-jvmRun1.dump, log,
> surefireargs8788494900922906864
>
>
> I tried to modularize my library. I turned it into a named module. Some of my
> dependencies are modules, however most of them are not, so I wanted to use
> them as automatic modules.
> However, it seems that for some reason, surefire puts quite a lot of things
> including many of automatic modules in the classpath instead of module path.
> Even worse, slf4j-simple-1.8.0-beta2, that is in test classpath and not
> directly required by my module, is also put in classpath, even though it is a
> named module!
> Also, as can be seen in attached logs, my tests try to instantiate a jaxb
> context, however it fails because jaxb implementation, put by surefire in
> classpath (unnamed module) cannot access the model package, even though the
> package in my library is opened to java.bind. Not sure if it would currently
> work if I somehow forced jaxb impls to go on modulepath, however it seems
> putting those deps in classpath may interfere with test results. adding
> --add-opens to open all library packages to all unnamed modules is not an
> option for this exact reason, because it doesn't verify if module is properly
> configured, correctly opening the package to java.xml.bind module.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
