[
https://issues.apache.org/jira/browse/SUREFIRE-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16184813#comment-16184813
]
Tibor Digana edited comment on SUREFIRE-1424 at 9/28/17 8:25 PM:
-----------------------------------------------------------------
I added {{--add-modules java.se.ee}} to Version {{2.20.1}} because we wanted to
fix such ClassLoader issues reported in Jira.
This is not a regression and not a bug in Surefire. This is actually problem
with Oracle because broke backwards compatibility. Several years ago Oracle
planned to design JDK in a way that JDK would be extensible. So if you imaging
that you put {{javax}} extensions JAR {{javax.transctions.jar}} as a module,
this could extend Java SE API with JTA from Java EE7.
This mechanism does not exist and the only thing is to apply {{--add-modules
java.se.ee}} or any other module in {{.mvn/jvm.config}} or add
{{javax:javaee-api:7.0}}.
Another issue is that Java API is not exposes however it is inside.
Oracle says that {{javax.xml.bind}} and {{javax.activation}} is EE related. I
disagree. This is also SE and people use it in console Swing applications. The
plan is to delete several APIs.
was (Author: tibor17):
I added {{--add-modules java.se.ee}} to Version {{2.20.1}} because we wanted to
fix such ClassLoader issues reported in Jira.
This is not a regression and not a bug in Surefire. This is actually problem
with Oracle because broke backwards compatibility. Several years ago Oracle
planned to design JDK in a way that JDK would be extensible. So if you imaging
that you put {{javax}} extensions JAR {{javax.transctions.jar}} as a module,
this could extend Java SE API with JTA from Java EE7.
Another issue is that Java API is not exposes however it is inside. This
mechanism does not exist and the only thing is to apply {{--add-modules
java.se.ee}} or any other module in {{.mvn/jvm.config}} or add
{{javax:javaee-api:7.0}}.
Oracle says that {{javax.xml.bind}} and {{javax.activation}} is EE related. I
disagree. This is also SE and people use it in console Swing applications. The
plan is to delete several APIs.
> javax.transaction.TransactionManager not visible with Java9
> -----------------------------------------------------------
>
> Key: SUREFIRE-1424
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1424
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
> Affects Versions: 2.20.1
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
> Maven home: /Users/snicoll/tools/maven
> Java version: 9, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
> Default locale: en_BE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
> Reporter: Stephane Nicoll
> Assignee: Tibor Digana
>
> I am trying to port Spring Boot to Java9 and I am hitting an issue that looks
> like Maven specific. I've managed to trim down the problem to [a simple class
> that doesn't involve Spring
> Boot|https://github.com/snicoll-scratches/test-jta-java9]
> If I run this project on the command line, I get the following:
> {noformat}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.043 s <<<
> FAILURE! - in com.example.testjtajava9.TestJtaJava9ApplicationTests
> contextLoads(com.example.testjtajava9.TestJtaJava9ApplicationTests) Time
> elapsed: 0.006 s <<< ERROR!
> java.lang.NoClassDefFoundError: javax/transaction/TransactionManager
> at
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> Caused by: java.lang.ClassNotFoundException:
> javax.transaction.TransactionManager
> at
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> {noformat}
> If I run that test with IntelliJ IDEA, it passes. This sample project has
> also a simple Gradle build that shows it works with Gradle as well.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
