Some testng tests fail when run with testng 6.9.8 but pass with testng 6.9.9.
For example:
java/lang/invoke/modules/Driver.java
Boot Layer
add modules: m1 m2 testng jcommander
module path: /home/martin/ws/jdk10/test/jdk/JTwork/classes/java/lang/invoke/modules/Driver.d/modules
/home/martin/ws/jdk10/test/jdk/JTwork/modules
STDOUT:
Error occurred during initialization of boot layer
java.lang.module.FindException: Unable to derive module descriptor for /home/martin/ws/jdk10/test/jdk/JTwork/modules/testng.jar
Caused by: java.lang.module.InvalidModuleDescriptorException: ConverterSample4.class found in top-level directory (unnamed package not allowed in module)
---
Indeed testng 6.9.8 (as downloaded from Maven Central) has top level class files, probably a packaging error corrected in testng 6.9.9. Fix is easy - if testng 6.9.9 works, then use it! Well, we're doing that... BUT ...
WHY is jtreg trying to use testng as a module at all? It's converting it into an automatic module perhaps? But isn't that a bug? jtreg should not be treating arbitrary jar files as automatic modules
For example:
java/lang/invoke/modules/Driver.java
Boot Layer
add modules: m1 m2 testng jcommander
module path: /home/martin/ws/jdk10/test/jdk/JTwork/classes/java/lang/invoke/modules/Driver.d/modules
/home/martin/ws/jdk10/test/jdk/JTwork/modules
STDOUT:
Error occurred during initialization of boot layer
java.lang.module.FindException: Unable to derive module descriptor for /home/martin/ws/jdk10/test/jdk/JTwork/modules/testng.jar
Caused by: java.lang.module.InvalidModuleDescriptorException: ConverterSample4.class found in top-level directory (unnamed package not allowed in module)
---
Indeed testng 6.9.8 (as downloaded from Maven Central) has top level class files, probably a packaging error corrected in testng 6.9.9. Fix is easy - if testng 6.9.9 works, then use it! Well, we're doing that... BUT ...
WHY is jtreg trying to use testng as a module at all? It's converting it into an automatic module perhaps? But isn't that a bug? jtreg should not be treating arbitrary jar files as automatic modules