Is there a way to disable this hack? I am trying to build the glassfish-corba project <https://github.com/javaee/glassfish-corba>, 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 <[email protected]> wrote: > > 2017-09-29 10:41 GMT+02:00 Alan Bateman <[email protected]>: > >> 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 >> >> >> >> >>
