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.
> 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-plugin</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-unsubscr...@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
> >
> >
>
