You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Karl Heinz Marbaise <kh...@gmx.de> on 2017/06/17 13:54:06 UTC

JDK9: Jigsaw Problem with maven-site-plugin 3.6

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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: JDK9: Jigsaw Problem with maven-site-plugin 3.6

Posted by Robert Scholte <rf...@apache.org>.
On Mon, 19 Jun 2017 13:21:22 +0200, Enrico Olivelli <eo...@gmail.com>  
wrote:

> 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

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.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 <eo...@gmail.com>:
>>
>>
>> Il dom 18 giu 2017, 09:38 Tibor Digana <ti...@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 <rf...@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-unsubscribe@maven.apache.org
>>> >>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>> >> For additional commands, e-mail: dev-help@maven.apache.org
>>> >>
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> > For additional commands, e-mail: dev-help@maven.apache.org
>>> >
>>> >
>>>
>>>
>>> --
>>> Cheers
>>> Tibor
>>
>> --
>>
>>
>> -- Enrico Olivelli
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: JDK9: Jigsaw Problem with maven-site-plugin 3.6

Posted by Enrico Olivelli <eo...@gmail.com>.
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 <eo...@gmail.com>:
>
>
> Il dom 18 giu 2017, 09:38 Tibor Digana <ti...@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 <rf...@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-unsubscribe@maven.apache.org
>> >>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>>
>>
>> --
>> Cheers
>> Tibor
>
> --
>
>
> -- Enrico Olivelli

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: JDK9: Jigsaw Problem with maven-site-plugin 3.6

Posted by Enrico Olivelli <eo...@gmail.com>.
Il dom 18 giu 2017, 09:38 Tibor Digana <ti...@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 <rf...@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-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> --
> Cheers
> Tibor
>
-- 


-- Enrico Olivelli

Re: JDK9: Jigsaw Problem with maven-site-plugin 3.6

Posted by Tibor Digana <ti...@googlemail.com>.
@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 <rf...@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
Cheers
Tibor

Re: JDK9: Jigsaw Problem with maven-site-plugin 3.6

Posted by Robert Scholte <rf...@apache.org>.
+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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: JDK9: Jigsaw Problem with maven-site-plugin 3.6

Posted by Guillaume Boué <gb...@apache.org>.
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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: JDK9: Jigsaw Problem with maven-site-plugin 3.6

Posted by Enrico Olivelli <eo...@gmail.com>.
Il sab 17 giu 2017, 16:40 Karl Heinz Marbaise <kh...@gmx.de> ha
scritto:

> Hi,
>
> If i correctly understand the error message it would help having a
> module-info.java with a proper name and a require clause to say that we
> need access to java.io.File...
> Currently we have a unnamed module which prevents such access...
>

IMHO The java.base module should give you access, but you cannot change it
and your module cannot request access to internals of other modules, that
would break strong encapsulation, this is the great value of jigsaw, most
of the problems nowadays are due to legacy java code which bypasses
encapsulation by using setAccessible.

Enrico

>
>
>
>
> Kind regards
> Karl Heinz Marbaise
> On 17/06/17 16:31, Enrico Olivelli wrote:
> > Karl,
> > I think that the problem is tha code is trying to access internals of
> > java.io.File.
> > No module descriptor can help.
> > I think you should run with -X, get the stacktrace of the exception and
> > then we need to avoid that reflective call.
> > In the meantime you can use the famous big kill switch.
> > Hope that helps
> > I will be happy to check the problem next week and help if possible
> >
> >
> > Enrico
> >
> > Il sab 17 giu 2017, 15:54 Karl Heinz Marbaise <khmarbaise@gmx.de
> > <ma...@gmx.de>> ha scritto:
> >
> >     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 <http://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 <http://java.io>;
> >         requires java.base;
> >     }
> >
> >     Do we have any kind of general naming convention for the plugins?
> >
> >     Kind regards
> >     Karl Heinz Marbaise
> >
>
-- 


-- Enrico Olivelli

Re: JDK9: Jigsaw Problem with maven-site-plugin 3.6

Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,

If i correctly understand the error message it would help having a 
module-info.java with a proper name and a require clause to say that we 
need access to java.io.File...
Currently we have a unnamed module which prevents such access...

Kind regards
Karl Heinz Marbaise
On 17/06/17 16:31, Enrico Olivelli wrote:
> Karl,
> I think that the problem is tha code is trying to access internals of 
> java.io.File.
> No module descriptor can help.
> I think you should run with -X, get the stacktrace of the exception and 
> then we need to avoid that reflective call.
> In the meantime you can use the famous big kill switch.
> Hope that helps
> I will be happy to check the problem next week and help if possible
> 
> 
> Enrico
> 
> Il sab 17 giu 2017, 15:54 Karl Heinz Marbaise <khmarbaise@gmx.de 
> <ma...@gmx.de>> ha scritto:
> 
>     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 <http://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 <http://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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: JDK9: Jigsaw Problem with maven-site-plugin 3.6

Posted by Enrico Olivelli <eo...@gmail.com>.
Karl,
I think that the problem is tha code is trying to access internals of
java.io.File.
No module descriptor can help.
I think you should run with -X, get the stacktrace of the exception and
then we need to avoid that reflective call.
In the meantime you can use the famous big kill switch.
Hope that helps
I will be happy to check the problem next week and help if possible


Enrico

Il sab 17 giu 2017, 15:54 Karl Heinz Marbaise <kh...@gmx.de> ha
scritto:

> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
> --


-- Enrico Olivelli