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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Enrico Olivelli
Il sab 17 giu 2017, 16:40 Karl Heinz Marbaise <[hidden email]> 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 <[hidden email]
> > <mailto:[hidden email]>> 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
Reply | Threaded
Open this post in threaded view
|

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

rfscholte
+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é <[hidden email]>  
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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Enrico Olivelli
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 <[hidden email]>:

>
>
> Il dom 18 giu 2017, 09:38 Tibor Digana <[hidden email]> 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 <[hidden email]>
>> 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é <[hidden email]>
>> > 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: [hidden email]
>> >>> For additional commands, e-mail: [hidden email]
>> >>>
>> >>>
>> >>
>> >> ---
>> >> 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: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>> >
>>
>>
>> --
>> Cheers
>> Tibor
>
> --
>
>
> -- Enrico Olivelli

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]