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

[Russell Gold]

Is there a way to disable this hack? 

I am trying to build the glassfish-corba project 
, which defines its own version of 
classes in the javax.rmi.CORBA package, and having --add-modules java.se.ee on 
the command line means that those classes aren’t found during unit tests.

- Russ

> On Sep 29, 2017, at 4:55 AM, Enrico Olivelli  wrote:
> 
> 2017-09-29 10:41 GMT+02:00 Alan Bateman :
> 
>> 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
>> 
>> 
>> 
>> 
>> 

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

[Enrico Olivelli]

2017-09-29 10:41 GMT+02:00 Alan Bateman :

> 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
>
>
>
>
>

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

[Alan Bateman]

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. 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





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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

[Enrico Olivelli]

Robert, Tibor,
I agree with Robert that the tweak about adding --add-modules java.se.ee
has really limited effect as I pointed out in another private email thread,
actually the hack does not work with more than one forked JVM.

My proposal is to drop that fix and document how to deal with changes in
java9, most of the tricks are:
- using JDK_JAVA_OPTIONS=--add-modules=java.se.ee
- using .mvn/jvm.config
- using profiles activated on java version >= 9
- adding explicit dependencies for APIs dropped by default (non included in
java.base)

I have some issues which I cannot resolve:
1) licensing about those new dependencies
if you load javax.xml. from the JDK you do not have to redistribute it,
but if you bundle those jars within your app maybe you will not be happy
about the CCDL license

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

Enrico


2017-09-29 9:35 GMT+02:00 Robert Scholte :

> Hi Tibor,
>
> moving this to the dev-list, I don't think JIRA is the right place for
> this kind of discussions.
>
> bq. This is not a regression and not a bug in Surefire.
>
> Sorry, I don't agree with you. The Java8 project provided by Stéphane
> works with 2.20.0, but not with 2.20.1, so for me this is clearly a
> regression in surefire.
>
> We are all aware that the modularization in Java 9 can break things, and
> yes sometimes that can be quite frustrating. I think it is the task of
> Maven to solve these kind of issues where possible. Maven should solve the
> hard parts for using Java to let users experience a great way to develop
> with Java.
>
> I don't mind picking this issue up and try to get rid of the
> "--add-modules java.se.ee" (this issue just confirms to me it is indeed a
> hack). Alan pointed me to some dependencies we should add, which should
> solve this issue.
>
> Robert
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

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

[Robert Scholte]

Hi Tibor,

moving this to the dev-list, I don't think JIRA is the right place for  
this kind of discussions.


bq. This is not a regression and not a bug in Surefire.

Sorry, I don't agree with you. The Java8 project provided by Stéphane  
works with 2.20.0, but not with 2.20.1, so for me this is clearly a  
regression in surefire.


We are all aware that the modularization in Java 9 can break things, and  
yes sometimes that can be quite frustrating. I think it is the task of  
Maven to solve these kind of issues where possible. Maven should solve the  
hard parts for using Java to let users experience a great way to develop  
with Java.


I don't mind picking this issue up and try to get rid of the  
"--add-modules java.se.ee" (this issue just confirms to me it is indeed a  
hack). Alan pointed me to some dependencies we should add, which should  
solve this issue.


Robert

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org