Michał Zegan created SUREFIRE-1543:
--------------------------------------
Summary: 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
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)
