Karl,
I am getting this error using maven site plugin 3.6 and jdk 9-ea+174
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
@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
the error is different from yours
-- Enrico
this is the full stacktrace
...Caused by: java.lang.ExceptionInInitializerError
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
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 loaded
at 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
@7069f076
at
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 <eolive...@gmail.com>:
>
>
> Il dom 18 giu 2017, 09:38 Tibor Digana <tibor.dig...@googlemail.com> 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 hack
>> anyway 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 full
> java8 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 the
> transition. This is available from jdk9b172.
>
>
> As third party library providers all of us should update our code and remove
> illegal code.
>
>
>
>
>>
>> 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.
>
>
> 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 work
> on 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, Weblogic
>
>
> I 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 <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
>
> --
>
>
> -- Enrico Olivelli
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
