Karl, I am getting this error using maven site plugin 3.6 and jdk 9-ea+174java.lang.reflect.InaccessibleObjectException: Unable to make protected final java.lang.Class java.lang.ClassLoader.findLoadedClass(java.lang.String) accessible: module java.base does not "opens java.lang" to unnamed module @7069f076 .... at java.base/java.lang.reflect.Method.setAccessible(Method.java:192)at org.parboiled.transform.AsmUtils.findLoadedClass(AsmUtils.java:206)there is an issue already opened by Robert https://github.com/sirthias/parboiled/issues/104
This issue won't be fixed because parboiled is not maintained anymore. Doxia-pegdown should switch to flexmark-java[1]
Robert [1] https://issues.apache.org/jira/browse/DOXIA-553
the error is different from yours -- Enrico this is the full stacktrace ...Caused by: java.lang.ExceptionInInitializerErrorat java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(NativeMethod)at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:488) at com.google.inject.internal.DefaultConstructionProxyFactory$1.newInstance(DefaultConstructionProxyFactory.java:86) at com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:105) at com.google.inject.internal.ConstructorInjector.access$000(ConstructorInjector.java:32) at com.google.inject.internal.ConstructorInjector$1.call(ConstructorInjector.java:89) at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115) at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:133) at com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68) at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:87) at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:267) at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016) at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103) at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012) at com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1051) at org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48) at com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:81) at com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:53) at com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:65) at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115) at org.eclipse.sisu.bean.BeanScheduler$CycleActivator.onProvision(BeanScheduler.java:230) at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:126) at com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68) at com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:63) at com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45) at com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46) at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103) at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40) at com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:145) at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41) at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016) at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1092) at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012) at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:81) at org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)at java.base/java.util.AbstractMap.get(AbstractMap.java:187)at org.apache.maven.doxia.parser.manager.DefaultParserManager.getParser(DefaultParserManager.java:46) at org.apache.maven.doxia.DefaultDoxia.getParser(DefaultDoxia.java:72) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(DefaultSiteRenderer.java:367) at org.apache.maven.doxia.siterenderer.DoxiaDocumentRenderer.renderDocument(DoxiaDocumentRenderer.java:53) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:337) at org.apache.maven.plugins.site.render.SiteMojo.renderDoxiaDocuments(SiteMojo.java:262) at org.apache.maven.plugins.site.render.SiteMojo.renderLocale(SiteMojo.java:168) at org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:132) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)... 21 more Caused by: java.lang.RuntimeException: Error creating extended parser class: Could not determine whether class 'org.pegdown.Parser$$parboiled' has already been loaded at org.parboiled.Parboiled.createParser(Parboiled.java:58) at org.pegdown.PegDownProcessor.<init>(PegDownProcessor.java:66)at org.apache.maven.doxia.module.markdown.MarkdownParser.<clinit>(MarkdownParser.java:72)... 68 more Caused by: java.lang.RuntimeException: Could not determine whether class 'org.pegdown.Parser$$parboiled' has already been loadedat org.parboiled.transform.AsmUtils.findLoadedClass(AsmUtils.java:213) at org.parboiled.transform.ParserTransformer.transformParser(ParserTransformer.java:35)at org.parboiled.Parboiled.createParser(Parboiled.java:54) ... 70 more Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make protected final java.lang.Class java.lang.ClassLoader.findLoadedClass(java.lang.String) accessible: module java.base does not "opens java.lang" to unnamed module @7069f076at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:337) at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:281) at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:198)at java.base/java.lang.reflect.Method.setAccessible(Method.java:192)at org.parboiled.transform.AsmUtils.findLoadedClass(AsmUtils.java:206)... 72 more 2017-06-18 11:04 GMT+02:00 Enrico Olivelli <[email protected]>:Il dom 18 giu 2017, 09:38 Tibor Digana <[email protected]> ha scritto:@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 hackanyway as it first seems. Strong encapsulation in Java9 can be openly passed by.This is not about strong encapsulation per se, but it adds automatically every known system module to the module path.By default new java apps will see only the java.se module and not the fulljava8 jdk, which can be referenced using the java.se.ee module. It is a big jump and it makes impossible to simply upgrade your java installation from java8 to java9 and hope it will work From my point of view the big problem is that existing libraries broke encapsulation of jdk.Recently there was a decision to allow illegal reraccessflective access by default to every legacy classpath based application and, this will ease thetransition. This is available from jdk9b172.As third party library providers all of us should update our code and removeillegal code.For instance in Surefire we extend UrlClassLoader and I need to accessentire Java API and let our users to load their classes with entire JavaAPI 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.Honestly I do not know either. Maybe surefire should do its magic and make jdk8 apps work as before but for the otherside in real world they won't workon java9 without additional command line options Enrico[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, WeblogicI think that this could be a good read about this topic http://www.tomitribe.com/blog/2017/05/is-jigsaw-dead-not-quite/On Sat, Jun 17, 2017 at 9:53 PM, Robert Scholte <[email protected]> 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é <[email protected]> > 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: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> --->> 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: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Cheers Tibor-- -- Enrico Olivelli--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
