Re: [jira] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: [jira] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9

Enrico Olivelli
2017-09-29 10:41 GMT+02:00 Alan Bateman <[hidden email]>:

> On 29/09/2017 08:57, Enrico Olivelli wrote:
>
>> :
>>
>> 2) dealing with modules like java.sql which as not in java.base (
>> http://download.java.net/java/jdk9/docs/api/java.base-summary.html)
>> Currently I have no solution as there is no official maven dependency for
>> java.sql package
>>
>> You shouldn't need to be concerned with the java.sql module.


From the point of view of a developer which uses Maven there is no Maven
style way to use java.sql module, like "adding a dependency"
The hack on surefire tried to solve this problem.

Using JDK_JAVA_OPTIONS is an option, but as it is a env entry it must be
set externally to the maven pom.xml or config
Using .mvn/jvm.config will prevent the build to work on java8 (except from
using -XX:+IgnoreUnrecognizedVMOptions which will be dropped in java11 ??)

Which is the best suggestion to give to maven users ?

-- Enrico



> The only modules that you need to be concerned about are:
>
> java.corba
> java.transaction
> java.activation
> java.xml.bind
> java.xml.ws
> java.xml.ws.annotation
>
> and the java.se.ee aggregator.
>
> These modules are deprecated in Java SE and are proposed to be removed in
> a future release.
>
> Aside from java.corba, the 5 modules shared with Java EE are standalone
> technologies, each with one or more JSRs and its own download. Each of
> these projects used to be on java.net but moved to the Java EE github
> project recently. I don't know if the move to Eclipse will change anything
> there.
>
> In any case, each of the standalone versions can be deployed on the class
> path with JDK 9.
>
> In time they will be deployable as modules too and this will allow them to
> be deployed on the upgrade module path (--upgrade-module-path) to
> upgrade/override the module in the run-time image with the standalone or
> Java EE module. This will actually work with all except for the transaction
> API as there are a couple of issues to sort out there before it can be
> deployed as a module.
>
> As I understand it, the Spring folks in the JIRA issue are deploying the
> JTA JAR file on the class path. That should just work but is complicated by
> `--add-module=java.se.ee` as that will cause the java.transaction module
> to be resolved. You can't split the javax.transaction package between a
> module and the class path.
>
> For the surefire plugin then dropping the --add-modules should be looked
> at. You'll need to do that anyway once java.se.ee goes away. If the
> plugin relies on JAXB then adding a dependency on the standalone version
> should work.
>
> -Alan
>
>
>
>
>