Still I do not understand what is the difference between *all_system*
and *java.se.ee
<http://java.se.ee>*.
Is it a bug that proprietary package *jdk.incubator.httpclient* is in the
warning? It looks like it wants to be exposed out of the jdk to our
application which is not legal but then why jdk allows.

On Wed, Aug 16, 2017 at 8:06 AM, Enrico Olivelli <eolive...@gmail.com>
wrote:

> Il mer 16 ago 2017, 02:44 Tibor Digana <tibordig...@apache.org> ha
> scritto:
>
> > 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
> >
>
> Yep, it is as I suspected. If we want ro get rid of it we have to only add
> java.se.ee module
>
>
> > 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=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3
> wxNDIxNjZ8LTI4OTQ5MjEwMg==
> > >
> > > .
> > > 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.
>
> --
>
>
> -- Enrico Olivelli
>



-- 
Cheers
Tibor

Reply via email to