Hi Enrico, It does not appear on console output however it is stored as native std/out in target/surefire-reports/2017-08-13T23-52-13_184.dumpstream
On Tue, Aug 15, 2017 at 5:51 PM, Enrico Olivelli [via Maven] < ml+s40175n5912520...@n5.nabble.com> wrote: > Il dom 13 ago 2017, 17:31 Tibor Digana <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=5912520&i=0>> ha > scritto: > > > I found an issue. JDK printed this on std/out: > > WARNING: Using incubator modules: jdk.incubator.httpclient > > > > IMHO This is because we are importing all system modules. Maybe importing > only java.se.ee would cover most of the cases. > I did not notice the warning on test I have run today > > Enrico > > > > It hapens after my test: > > > > import org.junit.Test; > > > > public class J9Test > > { > > @Test > > public void testMiscellaneousAPI() throws java.sql.SQLException > > { > > System.out.println( "loaded class " + > > java.sql.SQLException.class.getName() ); > > System.out.println( "loaded class " + > > javax.xml.ws.Holder.class.getName() ); > > System.out.println( "loaded class " + > > javax.xml.bind.JAXBException.class.getName() ); > > System.out.println( "loaded class " + > > org.omg.CORBA.BAD_INV_ORDER.class.getName() ); > > System.out.println( "loaded class " + > > javax.xml.xpath.XPath.class.getName() ); > > System.out.println( "java.specification.version=" + > > System.getProperty( "java.specification.version" ) ); > > } > > > > @Test > > public void test_corba_mod() throws org.omg.CORBA.BAD_INV_ORDER > > { > > } > > } > > > > > > On Sun, Aug 13, 2017 at 5:29 PM, Tibor Digana <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=5912520&i=1> > > > > > wrote: > > > > > But why to add it? It's a hack. I do not use module-info.java and so > > there > > > is no reason to break the backwards compatibility. > > > > > > This is no more about Maven. It is about entire Java world. > > > If we in Maven do it then everybody has to. > > > And I am sure that the voices says that Kotlin is better and Scala is > > > better would make sense. Why to help these attempts to happen? No > reason! > > > > > > On Sun, Aug 13, 2017 at 5:11 PM, Gary Gregory <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=5912520&i=2>> > > > wrote: > > > > > >> Is there a Maven way to add ALL-SYSTEM to everything? Using plugin > > >> specific > > >> tags like below is going to be painful. > > >> > > >> Gary > > >> > > >> On Aug 13, 2017 07:30, "Tibor Digana" <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=5912520&i=3>> wrote: > > >> > > >> > Hi @Enrico, > > >> > > > >> > I am very unhappy with Java 9 status and very afraid. > > >> > I do not like the style how Oracle has changed Java to Java 9 and > > forced > > >> > all the world to use additional effort to adapt to Oracle > activities. > > >> > > > >> > I am facing more unhappy Java development teams with Java 9 in the > > >> future. > > >> > For instance as I have tried to implement users wish in Maven > Surefire > > >> > project and invested my personal time and effort to adapt to Oracle > > >> > requirements, this still does not convince me to say that Java 9 is > > >> ready > > >> > to go. > > >> > > > >> > This is my comment from Jira: > > >> > > > >> > "This is not nice on Java 9 that they broke backwards compatibility > > and > > >> > force the world to use the switch to use --add-modules ALL-SYSTEM > > >> instead > > >> > of providing all modules installed in JRE. For instance, small JRE > > >> having > > >> > {{java.base}} has advantage on embedded systems and the only should > be > > >> > propagated. Big scope JRE should propagate all installed modules. > > >> > But for me it does not make security sense and common sense to > force > > >> JRE to > > >> > provide modules. It should be opposite and the admin/Jenkins should > > >> > configure big scope JRE with selected modules propagated to Java > > runtime > > >> > applications. > > >> > If this admin does not do that then all modules should be available > by > > >> > default which is backwards compatibility for me and we do not have > to > > to > > >> > implement these stupid tricks." > > >> > > > >> > As far as we remember Java Security, the policies can be > configured. > > >> > I can imaging same paradigm in Jigsaw/Java 9 and then the admin who > > has > > >> > installed JDK or JRE would "switch off" some modules. But opposite, > > that > > >> > means the script which starts Java app currently enables "all" > modules > > >> is > > >> > against security and against the principle of modular system > because > > the > > >> > modules do not make sense then. > > >> > > > >> > What makes sense to me is to enable "all java/javax" modules except > > for > > >> the > > >> > "com.sun" proprietary ones by default. > > >> > So yes enable them by default and please release specific JRE > > >> installations > > >> > with specific bunch of Java modules for specific use cases. > > >> > This means those modules in that particular release are all enabled > by > > >> > default if not configured otherwise by admin, e.g. Jenkins, > operation > > >> > staff, etc. (do NOT mean Sun packages - never visible). > > >> > > > >> > Here it comes. The idea that we can install small 5MB/JRE on small > > Linux > > >> > device would be possible because Oracle would release such tiny JRE > > >> using > > >> > only "java.lang" and then another JRE installation using java.lang > and > > >> > java.utils, and later NIO and later "java.desktop", etc. > > >> > > > >> > Then vendors of web browsers and Linux dist would be happy to > > integrate > > >> > small JRE into and use JavaFX. > > >> > > > >> > But now it is not possible because the modules are basically three: > > >> > > > >> > java.base == 37MB > > >> > java.desktop == 36MB > > >> > java.xml ==20MB > > >> > > > >> > All the other modules are pretty small but these three seen in > > "src.zip" > > >> > make the modular system unbalanced in size and nobody would ever > wish > > to > > >> > integrate them because they are still big. That means the problem > that > > >> > Oracle has with NIO implementation in com.sun package propagated to > > >> > "java.util", nobody in the world care and nobody should see as a > > >> problem to > > >> > split "java.base" much more. > > >> > > > >> > If splitting "java.base" happened then not certified JVMs developed > at > > >> > Universities would for instance implement only "java.lang" and > embed > > it > > >> in > > >> > to JVM and develop a new programming language on the top of Java. > But > > >> > implementing 10 packages in java.base is an effort again. > > >> > > > >> > > > >> > > > >> > One more thing is regarding the size of the modules. > > >> > You really did not help embedded systems and installations of > > browsers. > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > On Thu, May 18, 2017 at 8:51 AM, Enrico Olivelli <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=5912520&i=4> > > > > > >> > wrote: > > >> > > > >> > > I would like to share my current pom configuration which lets me > to > > >> > > build and test java8 apps on latest and greatest jdk9 > > >> > > > > >> > > This profile is activated when using jdk9. > > >> > > > > >> > > This is based on a suggestion of Robert, its suggestion for the > > >> > > javadoc plugin is working great with surefire too > > >> > > > > >> > > <profile> > > >> > > <id>jdk9</id> > > >> > > <activation> > > >> > > <jdk>[9,)</jdk> > > >> > > </activation> > > >> > > <build> > > >> > > <plugins> > > >> > > <plugin> > > >> > > <groupId>org.apache.maven.plugins</groupId> > > > >> > > > > <artifactId>maven-javadoc-plugin</artifactId> > > >> > > <configuration> > > >> > > <additionalparam>--add-modules > > >> > > ALL-SYSTEM</additionalparam> > > >> > > </configuration> > > >> > > </plugin> > > >> > > <plugin> > > >> > > <groupId>org.apache.maven.plugins</groupId> > > > >> > > <artifactId>maven-surefire-pl > > >> ugin</artifactId> > > >> > > <version>2.20</version> > > >> > > <configuration> > > >> > > <argLine>--add-modules > > >> ALL-SYSTEM</argLine> > > >> > > </configuration> > > >> > > </plugin> > > >> > > </plugins> > > >> > > </build> > > >> > > </profile> > > >> > > > > >> > > > > >> > > -- Enrico > > >> > > > > >> > > > > >> > > > > >> > > 2017-04-24 19:08 GMT+02:00 Karl Heinz Marbaise <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=5912520&i=5>>: > > >> > > > Hi, > > >> > > > > > >> > > > yes I will do within this week... > > >> > > > > > >> > > > Kind regards > > >> > > > Karl Heinz Marbaise > > >> > > > On 23/04/17 21:37, Enrico Olivelli wrote: > > >> > > >> > > >> > > >> Thank you Robert, > > >> > > >> I saw that you have merged my patch. > > >> > > >> > > >> > > >> Is there any plan to release the new version of the war > plugin? > > >> > > >> > > >> > > >> Enrico > > >> > > >> > > >> > > >> > > >> > > >> Il gio 13 apr 2017, 12:21 Paul Hammant <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=5912520&i=6>> ha > > >> scritto: > > >> > > >> > > >> > > >>>> > > >> > > >>>> > > >> > > >>>>> I don't see any activity either, so my idea is to replace > > >> XStream, > > >> > > see > > >> > > >>>> > > >> > > >>>> MWAR-397[1] > > >> > > >>>> > > >> > > >>> > > >> > > >>> Just for the record, Jörg is working through the Java9 issues > > for > > >> > > XStream > > >> > > >>> presently - https://github.com/x-stream/ > xstream/commits/master > > >> > > >>> > > >> > > >>> - Paul > > >> > > > > > >> > > > > > >> > > > ------------------------------------------------------------ > > >> --------- > > >> > > > To unsubscribe, e-mail: [hidden email] > <http:///user/SendEmail.jtp?type=node&node=5912520&i=7> > > >> > > > For additional commands, e-mail: [hidden email] > <http:///user/SendEmail.jtp?type=node&node=5912520&i=8> > > >> > > > > > >> > > > > >> > > > > --------------------------------------------------------------------- > > >> > > To unsubscribe, e-mail: [hidden email] > <http:///user/SendEmail.jtp?type=node&node=5912520&i=9> > > >> > > For additional commands, e-mail: [hidden email] > <http:///user/SendEmail.jtp?type=node&node=5912520&i=10> > > >> > > > > >> > > > > >> > > > >> > > > > > > > > > > > > -- > > > Cheers > > > Tibor > > > > > > > > > > > -- > > Cheers > > Tibor > > > -- > > > -- Enrico Olivelli > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > http://maven.40175.n5.nabble.com/Building-a-Java9-project-just-using-JDK9- > tp5905517p5912520.html > To start a new topic under Maven Developers, email > ml+s40175n142166...@n5.nabble.com > To unsubscribe from Maven Developers, click here > <http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==> > . > NAML > <http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- View this message in context: http://maven.40175.n5.nabble.com/Building-a-Java9-project-just-using-JDK9-tp5905517p5912569.html Sent from the Maven Developers mailing list archive at Nabble.com.
