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
Robert, Tibor,
I agree with Robert that the tweak about adding --add-modules
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
- using .mvn/jvm.config
- using profiles activated on java version >= 9
- adding explicit dependencies for APIs dropped by default (non included in

I have some issues which I cannot resolve:
1) licensing about those new dependencies
if you load javax.xml.xxxx 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 (
Currently I have no solution as there is no official maven dependency for
java.sql package


2017-09-29 9:35 GMT+02:00 Robert Scholte <[hidden email]>:

> 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" (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: [hidden email]
> For additional commands, e-mail: [hidden email]