You will need the same tricks at runtime for the command line that Maven
might hide at build time... :-( I guess hacks like --add-modules ALL-SYSTEM
will become part of our daily grind...
Gary
On Tue, Aug 15, 2017 at 9:07 AM, Enrico Olivelli <eolive...@gmail.com>
wrote:
> Il mar 15 ago 2017, 00:03 Tibor Digana <tibor.dig...@googlemail.com> ha
> scritto:
>
> > I do not want to be too pessimistic but the inheritance of modules is
> > crucial for all the world.
> >
> > The common sense tells me that I should not release Java 9 on September,
> > 2017 unless Java EE application servers work properly.
> >
> > This would mean that JDBC is crucial as well as JAXB for JAX-WS/RS and
> > maybe we will find out new issues which regarding for module java.se.ee.
> >
> > Without waiting for JEE9 this release would be too fast.
> > Oracle had an ambition to align JSE9 release with JEE9 however JEE8 has
> not
> > yet been released even if the ambition was to develop JEE9 in parallel
> with
> > JEE8.
> >
> > Isn't this too fast for the release of JSE9?
> >
>
> We are all waiting java9 and all the new features, apart from jigsaw.
> I think that the strong encapsulation work will make development of the jdk
> more simple and new java releases will follow a faster pace.
> I am really worried about the lack of interest in defining exacly at least
> the behaviour of most used frameworks, first of all the wrb
> applications/servlet world
>
> I am happy that the maven world will make it easy to switch from java8 to
> java9 ad far as we can. Maybe most of developers which are using maven will
> not see all the tricks under the hood
>
> Thank you
>
>
> Enrico
>
>
> > I understand that development parties of application servers and
> libraries
> > suppliers are slow but this still would not guarantee that there is no
> risk
> > that Jigsaw project made some mistake which (if happens) cannot be taken
> > back after the final release of JSE9.
> >
> >
> >
> > On Mon, Aug 14, 2017 at 11:23 PM, Enrico Olivelli <eolive...@gmail.com>
> > wrote:
> >
> > > Il lun 14 ago 2017, 11:46 Tibor Digana <tibor.dig...@googlemail.com>
> ha
> > > scritto:
> > >
> > > > Hello Enrico,
> > > >
> > > > I fixed SUREFIRE-1403 and now Surefire works with Java 9.
> > > > I need an approval for the Jira SUREFIRE-1403 for you and Robert. Thx
> > in
> > > > advance.
> > > >
> > >
> > > I will check as soon as I wil be back from vacation. Thank you very
> much.
> > > For me it is very important
> > >
> > > >
> > > > I have added integration tests for Failsafe plugin, added
> > documentation "
> > > > java9.md" and removed JAXB which is located in module
> > > *javax.xml.binding*.
> > > >
> > > > *Here is a clarification on why I was unhappy with Java status and
> why
> > > > Surefire project could not run with Java 9 and how it was fixed:*
> > > >
> > > > Because of I used *javax.xml.binding*, plugin Failsafe did not run in
> > > > Java9.
> > > > Reason is that module *javax.xml.binding* is however in Java API but
> > not
> > > > propagated on classpath when running Maven process (different
> situation
> > > in
> > > > forked JVM in Surefire which is here fixed by SUREFIRE-1403).
> > > > This is strange and will be strange for most people, for instance in
> > our
> > > > *Java
> > > > EE project using REST* the WildFly server has to use *"--add-modules
> > > > ALL-SYSTEM"* in *jboss.sh* to make our applications working again.
> > > > As a solution in Surefire project I removed JAXB which was simple XML
> > in
> > > my
> > > > case but not simple in general.
> > > >
> > >
> > > I will have to do it for several projects, or at leastleast to add
> > > java.se.ee, in fact many programs need JDBCTO and it is excluded by
> > > default, that is weird to me
> > >
> > > >
> > > > Someone may say that "do not use Java 9 if you do not use Jigsaw
> > > > modularity".
> > > > But there are reasons where you will use it.
> > > > For instance new API in Java or Java EE 9 in the future.
> > > >
> > >
> > > The main reason for migration is to keep up to date, java8 will soon
> > reach
> > > EOL.
> > > Java9 comes with many improvements that just upgrading will speed up
> most
> > > applications, just think about nee compat strings. New API are great
> and
> > > were expected from long time ago, like the new Process API....
> > >
> > >
> > > > I do not think that using *"--add-modules ALL-SYSTEM"* is good
> > principle.
> > > >
> > >
> > > Yep, new applications will be more fine tuned, the problem here is only
> > for
> > > the migration
> > >
> > > As a workaround to this in Maven would be to develop *smart
> > > > maven-compiler-plugin* which automatically generates
> > *module-info.class*
> > > > upon import sections in Java classes and Maven dependencies.
> > > > Not easy I guess.
> > > >
> > >
> > > I think this will be not feasible in general and very dangerous and
> > maybe I
> > > hope maven will never do such things
> > >
> > > Cheers
> > > Enrico
> > >
> > > >
> > > >
> > > > On Mon, Aug 14, 2017 at 10:57 AM, Enrico Olivelli <
> eolive...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Il dom 13 ago 2017, 17:31 Tibor Digana <
> tibor.dig...@googlemail.com>
> > > ha
> > > > > scritto:
> > > > >
> > > > > > I found an issue. JDK printed this on std/out:
> > > > > > WARNING: Using incubator modules: jdk.incubator.httpclient
> > > > > >
> > > > > > 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 <
> > > > > tibor.dig...@googlemail.com
> > > > > > >
> > > > > > 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 <
> > > > garydgreg...@gmail.com>
> > > > > > > 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" <tibordig...@apache.org
> >
> > > > wrote:
> > > > > > >>
> > > > > > >> > Hi @Enrico,
> > > > > > >> >
> > > > > > >> > I am very unhappy with Java 9 status and very afraid.
> > > > > >
> > > > >
> > > > > Tibor, thank you very much for your time and your effort.
> > > > > I think that we should have chimed in long time before the approval
> > of
> > > > > those decisions on the jre. Now the game is over, we can only
> decide
> > > how
> > > > > maven users will deal with running classpath based applications on
> > > java9.
> > > > > I see two approaches:
> > > > > 1) add a lot of tricks in every base maven plugin and make it very
> > easy
> > > > to
> > > > > transition
> > > > > 2) leave the complexity to developers who will add a lot of
> profiles
> > > and
> > > > > hacks to detect java9
> > > > >
> > > > > My personal feeling is that I am very disappointed by the fact the
> > few
> > > > > developers diffs not report this issues to the maven community long
> > > time
> > > > > ago. I think that the java9 adoption has not been taken into
> account
> > by
> > > > > most developers and this will be an huge pain for the java
> community.
> > > > > I hope that Maven will help the java world to go on and to step
> over
> > > this
> > > > > painful transition
> > > > >
> > > > > I will test your patch as soon as I can
> > > > > Cheers
> > > > > Enrico
> > > > >
> > > > > >> > 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 <
> > > > > eolive...@gmail.com
> > > > > > >
> > > > > > >> > 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 <
> > > > khmarba...@gmx.de
> > > > > >:
> > > > > > >> > > > 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 <
> p...@hammant.org
> > >
> > > 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: dev-unsubscribe@maven.apache.
> org
> > > > > > >> > > > For additional commands, e-mail:
> > dev-h...@maven.apache.org
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> > >
> > > > > > ------------------------------------------------------------
> > > ---------
> > > > > > >> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > > > >> > > For additional commands, e-mail:
> dev-h...@maven.apache.org
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Cheers
> > > > > > > Tibor
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Cheers
> > > > > > Tibor
> > > > > >
> > > > > --
> > > > >
> > > > >
> > > > > -- Enrico Olivelli
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Cheers
> > > > Tibor
> > > >
> > > --
> > >
> > >
> > > -- Enrico Olivelli
> > >
> >
> >
> >
> > --
> > Cheers
> > Tibor
> >
> --
>
>
> -- Enrico Olivelli
>
