@Enrico What "--add-modules ALL-SYSTEM" really does ? For me it would be maybe a handy hack but for you it would be just a hack anyway as it first seems. Strong encapsulation in Java9 can be openly passed by.
For instance in Surefire we extend UrlClassLoader and I need to access entire Java API and let our users to load their classes with entire Java API as in Java 8. Suppose no module-info is embedded in any jar. Before my plan was to call [1] findClass(String moduleName, String name) in subclass of UrlClassLoader with javase-ee in moduleName. Now I don't know which approach is better. [1]: http://download.java.net/java/jdk9/docs/api/java/lang/ClassLoader.html#findClass-java.lang.String-java.lang.String- Offtopic: I see several Java EE vendors voted against Jigsaw release of JDK9. I think JCP members should guarantee that application servers [2] are compliant with JDK9 in first step and then cut release version JDK 9 of Java SE. Otherwise Jigsaw may kill Java. [2]: TomEE, JBoss, WebSphere, GlassFish, WildFly, Weblogic On Sat, Jun 17, 2017 at 9:53 PM, Robert Scholte <rfscho...@apache.org> wrote: > +1, fully agree with Guillaume > > There's no real need to make a plugin modular: it won't become a > dependency and the dependency management as done by Maven is strong enough > to have a stable plugin (i.e no need to add requires-statements). > > In case of experiment if you want to add a module name, > "org.apache.maven.plugins.site" would be my choice as well. > > Robert > > > On Sat, 17 Jun 2017 16:31:14 +0200, Guillaume Boué <gb...@apache.org> > wrote: > > Hi, >> >> There was a link to Stephen Colebourne's blog about naming modules: >> http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html. So what >> about "org.apache.maven.plugins.site" for the module name? >> >> But I don't think it is necessary to make the plugin modular. The error >> means that code launched by the Site plugin is trying to access the private >> "File(String,File)" constructor. Can you turn on stacktraces to see what >> part of the code is doing that? We can perhaps fix the deep reflection >> usage and only rely on public API. >> >> I've also noticed MSITE-789 about a similar error but it was in Findbugs >> code. >> >> Guillaume >> >> Le 17/06/2017 à 15:54, Karl Heinz Marbaise a écrit : >> >>> Hi, >>> currently I'm a bit on testing JDK 9 EA+174..and found the following >>> issue: >>> >>> [INFO] >>> [INFO] <<< maven-plugin-plugin:3.4:report < process-classes @ >>> maven-install-plugin <<< >>> [INFO] >>> [INFO] 'process-classes' forked phase execution for >>> maven-plugin-plugin:report report preparation done >>> [INFO] configuring report plugin org.apache.maven.plugins:maven >>> -invoker-plugin:2.0.0 >>> [INFO] ------------------------------------------------------------ >>> ------------ >>> [INFO] BUILD FAILURE >>> [INFO] ------------------------------------------------------------ >>> ------------ >>> [INFO] Total time: 14.810 s >>> [INFO] Finished at: 2017-06-17T15:47:38+02:00 >>> [INFO] Final Memory: 57M/256M >>> [INFO] ------------------------------------------------------------ >>> ------------ >>> [ERROR] Failed to execute goal >>> org.apache.maven.plugins:maven-site-plugin:3.6:site >>> (default-site) on project maven-install-plugin: Execution default-site of >>> goal org.apache.maven.plugins:maven-site-plugin:3.6:site failed: Unable >>> to make private java.io.File(java.lang.String,java.io.File) accessible: >>> module java.base does not "opens java.io" to unnamed module @44b002c9 >>> -> [Help 1] >>> [ERROR] >>> [ERROR] To see the full stack trace of the errors, re-run Maven with the >>> -e switch. >>> [ERROR] Re-run Maven using the -X switch to enable full debug logging. >>> [ERROR] >>> >>> So based on what I understood at the moment is that the >>> maven-site-plugin needs to have a module-info.java file.... >>> >>> The first thing which came into my mind was how-to name the module? >>> >>> module org.apache.maven.plugins.maven.site.plugin { >>> requires java.io; >>> requires java.base; >>> } >>> >>> Do we have any kind of general naming convention for the plugins? >>> >>> Kind regards >>> Karl Heinz Marbaise >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> >> >> --- >> L'absence de virus dans ce courrier électronique a été vérifiée par le >> logiciel antivirus Avast. >> https://www.avast.com/antivirus >> >> >> --------------------------------------------------------------------- >> 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 > > -- Cheers Tibor
