Unable to derive module descriptor for gradle-api-5.6.2.jar — Provider class moduleName=model-core not in module

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Unable to derive module descriptor for gradle-api-5.6.2.jar — Provider class moduleName=model-core not in module

Plugins
While trying to find a solution to what I lovingly call Gradle's
„Anti-JPMS“ issue [1], I discovered that even if that one particular
issue is worked around, Gradle then, frustratingly, presents yet another
hurdle to developing with the JPMS! Specifically, it co-opts the
META-INF/services mechanism to bundle a non-JAR file-spec-compliant
services configuration file.


That technically-inappropriate
META-INF/services/org.codehaus.groovy.runtime.ExtensionModule entry in
Gradle's gradle-api-{version}.jar file is used by Gradle to extend the
Groovy language; which Gradle relies on. Apparently, that service entry
extends Groovy with Java methods [2].


The contents of that file...


   moduleName=model-core
   moduleVersion=1.0
 
extensionClasses=org.gradle.api.internal.provider.MapPropertyExtensions


...breaks Jigsaw when gradle-api-{version}.jar is in the module path
(for Gradle plugin development, say). A Gradle Test Task configured for
JPMS modules — as discussed in the Gradle documentation [3] — will
result in Gradle producing a command like this for example:


 
    java --module-path
<$GRADLE_USER_HOME>/.../gradle-api-5.6.2.jar:mymods/foo.jar:...
--patch-module mymod=/path/to/test/classes ...




When Gradle's Test Runner tries to execute that command, this is the
result:


    ...[QUIET] [system.out] Error occurred during initialization of boot
layer
    ...[QUIET] [system.out] java.lang.module.FindException: Unable to
derive module descriptor for
{$GRADLE_USER_HOME}/caches/5.6.2/generated-gradle-jars/gradle-api-5.6.2.jar
    ...[QUIET] [system.out] Caused by:
java.lang.module.InvalidModuleDescriptorException: Provider class
moduleName=model-core not in module


@AlanBateman? Please can you suggest what can be done to work around
Gradle's moduleName=model-core „anti-JPMS“ blocker?

Thanks in advance.

----
[1] http://bit.ly/antiJPMS
[2] http://bit.ly/CoOptSvcMech
[3] http://bit.ly/BldJ9Guide
Reply | Threaded
Open this post in threaded view
|

Re: Unable to derive module descriptor for gradle-api-5.6.2.jar — Provider class moduleName=model-core not in module

Alex Buckley
On 10/11/2019 3:41 PM, Plugins wrote:
> That technically-inappropriate
> META-INF/services/org.codehaus.groovy.runtime.ExtensionModule entry in
> Gradle's gradle-api-{version}.jar file is used by Gradle to extend the
> Groovy language; which Gradle relies on. Apparently, that service entry
> extends Groovy with Java methods [2].

As I write this email, the most recent comment at [2] is:

-----
alan.bateman2 • 2 years ago

META-INF/services is specified in the JAR file spec as the location for
services configuration files. It's not appropriate to put properties
file in this location. Can the Groovy extension mechanism use a
different location?
-----

> The contents of that file...
>
>     moduleName=model-core
>     moduleVersion=1.0
>    
> extensionClasses=org.gradle.api.internal.provider.MapPropertyExtensions
>
> ...breaks Jigsaw when gradle-api-{version}.jar is in the module path
> (for Gradle plugin development, say).

Then gradle-api-{version}.jar can't be used as an automatic module.

Since Cedric Champeau was writing to jdk-dev earlier today, I have taken
the liberty of cc'ing him in the hope that he can share Gradle's plans
for fixing this.

Alex
Reply | Threaded
Open this post in threaded view
|

Re: Unable to derive module descriptor for gradle-api-5.6.2.jar — Provider class moduleName=model-core not in module

Alan Bateman
In reply to this post by Plugins
On 11/10/2019 23:41, Plugins wrote:
> While trying to find a solution to what I lovingly call Gradle's
> „Anti-JPMS“ issue [1],
Just on this one, the analysis in the issue seems to be correct. Gradle
seems to have re-packaged the BC provider into the
org.gradle.internal.impldep.org.bouncycastle name space but missed the
services configuration file. There could issues here on multiple levels
that are nothing to do with modules.

-Alan
Reply | Threaded
Open this post in threaded view
|

Re: Unable to derive module descriptor for gradle-api-5.6.2.jar — Provider class moduleName=model-core not in module

Jochen Theodorou
In reply to this post by Plugins
On 12.10.19 00:41, Plugins wrote:

> While trying to find a solution to what I lovingly call Gradle's
> „Anti-JPMS“ issue [1], I discovered that even if that one particular
> issue is worked around, Gradle then, frustratingly, presents yet another
> hurdle to developing with the JPMS! Specifically, it co-opts the
> META-INF/services mechanism to bundle a non-JAR file-spec-compliant
> services configuration file.
>
>
> That technically-inappropriate
> META-INF/services/org.codehaus.groovy.runtime.ExtensionModule entry in
> Gradle's gradle-api-{version}.jar file is used by Gradle to extend the
> Groovy language; which Gradle relies on. Apparently, that service entry
> extends Groovy with Java methods [2].

No idea what gradle uses here, but the standard mechanism uses now
META-INF/groovy/org.codehaus.groovy.runtime.ExtensionModule
(https://issues.apache.org/jira/browse/GROOVY-8480). So I assume Gradle
is there still on Groovy 2.4

[...]
> @AlanBateman? Please can you suggest what can be done to work around
> Gradle's moduleName=model-core „anti-JPMS“ blocker?

you can try upgrading to Groovy 2.5. Never tried that, no idea what
problems appear as part of that. This change in the extension module
handling is not the only one, hence the new version. Or you remove the
file and see what breaks. I think patching is out of question here...

bye Jochen
Reply | Threaded
Open this post in threaded view
|

Re: Unable to derive module descriptor for gradle-api-5.6.2.jar — Provider class moduleName=model-core not in module

Alex Buckley
In reply to this post by Alex Buckley
Replying to the mailing list so that our new friend "lingocoder" can
take action on the bug (which Alan and Jochen have helpfully diagnosed
elsewhere in this thread).

Alex

On 10/11/2019 10:05 PM, Cédric Champeau wrote:

> Looks like the extension file is located in the old path which Groovy
> used. Would you mind creating an issue for this ?
>
> Le sam. 12 oct. 2019 à 01:52, Alex Buckley <[hidden email]
> <mailto:[hidden email]>> a écrit :
>
>     On 10/11/2019 3:41 PM, Plugins wrote:
>      > That technically-inappropriate
>      > META-INF/services/org.codehaus.groovy.runtime.ExtensionModule
>     entry in
>      > Gradle's gradle-api-{version}.jar file is used by Gradle to
>     extend the
>      > Groovy language; which Gradle relies on. Apparently, that service
>     entry
>      > extends Groovy with Java methods [2].
>
>     As I write this email, the most recent comment at [2] is:
>
>     -----
>     alan.bateman2 • 2 years ago
>
>     META-INF/services is specified in the JAR file spec as the location for
>     services configuration files. It's not appropriate to put properties
>     file in this location. Can the Groovy extension mechanism use a
>     different location?
>     -----
>
>      > The contents of that file...
>      >
>      >     moduleName=model-core
>      >     moduleVersion=1.0
>      >
>      >
>     extensionClasses=org.gradle.api.internal.provider.MapPropertyExtensions
>      >
>      > ...breaks Jigsaw when gradle-api-{version}.jar is in the module path
>      > (for Gradle plugin development, say).
>
>     Then gradle-api-{version}.jar can't be used as an automatic module.
>
>     Since Cedric Champeau was writing to jdk-dev earlier today, I have
>     taken
>     the liberty of cc'ing him in the hope that he can share Gradle's plans
>     for fixing this.
>
>     Alex
>
Reply | Threaded
Open this post in threaded view
|

RE: Unable to derive module descriptor for gradle-api-5.6.2.jar — Provider class moduleName=model-core not in module

Plugins
In reply to this post by Plugins
Hi,

{And sorry about my messages not being connected to the thread. I can't
get my webmail to do the right thing}

Github.com have finally unflagged my account now. Their „spam
blocker“ objected to something of mine somewhere — allegedly.

Anyway, the two issues and the one pull request [1] are visible again.


----
[1] http://bit.ly/PR11039
----

-------- Original Message --------
Subject: RE: Re: Unable to derive module descriptor for gradle-api-5
.6.2.jar — Provider class module Name=model-core not in module
From: "Plugins" <[hidden email]>
Date: Tue, October 15, 2019 10:54 am
To: "Alex Buckley" <[hidden email]>,
[hidden email]

Yeah. Sorry about that. I don't know what's going on. But only seconds
after I pushed my change up to my forked gradle/gradle repo yesterday,
for some reason github.com flashed an angry red „Your account has been
flagged. Please contact support...“ message on every page I visit on
github. I contacted github.com support several hours ago. But they still
haven't replied.

They've disappeared from Gradle's issue page. They're titled
„Compliance with Groovy 2.5's Standard Mechanism...“ and
„Compliance with the JDK's Standard Mechanism...“. I can only see
them — with the „...flagged...“ message emblazoned across the top
— when I'm logged into github.com.

I was afraid something like this would happen. So shortly after I first
submitted the Groovy one, I saved it on the Wayback Machine [1] Stuff
like this isn't good for that conspiracy theorist in me ;)


----

[1] http://bit.ly/11028bak

----


-------- Original Message --------
Subject: Re:__Unable_to_derive_module_descriptor_for _gradle-api-5
.6.2.jar_—_Provider_class_module Name=model-core_n_ot_in_module
From: Alex Buckley <[hidden email]>
Date: Tue, October 15, 2019 8:50 am
To: [hidden email]

On 10/14/2019 9:07 PM, Plugins wrote:
> I've reported to Gradle's issue tracking system, both the
> java.security.Provider configuration file issue [1] and the
> org.codehaus.groovy.runtime.ExtensionModule configuration file issue [2].

Thanks very much. Strangely, AFAICT, the two issues you submitted have
disappeared -- they return 404 errors, and do not appear in the issue
list:

http://bit.ly/Issue11027
-> https://github.com/gradle/gradle/issues/11027

http://bit.ly/Issue11028
-> https://github.com/gradle/gradle/issues/11028

Alex


Reply | Threaded
Open this post in threaded view
|

Re: Unable to derive module descriptor for gradle-api-5.6.2.jar — Provider class moduleName=model-core not in module

Alex Buckley
Good to see ... I'm sure you'll let jigsaw-dev know when a new version
of Gradle is usable as automatic modules.

Alex

On 10/16/2019 7:21 AM, Plugins wrote:

> Hi,
>
> {And sorry about my messages not being connected to the thread. I can't
> get my webmail to do the right thing}
>
> Github.com have finally unflagged my account now. Their „spam
> blocker“ objected to something of mine somewhere — allegedly.
>
> Anyway, the two issues and the one pull request [1] are visible again.
>
>
> ----
> [1] http://bit.ly/PR11039
> ----
>
> -------- Original Message --------
> Subject: RE: Re: Unable to derive module descriptor for gradle-api-5
> .6.2.jar — Provider class module Name=model-core not in module
> From: "Plugins" <[hidden email]>
> Date: Tue, October 15, 2019 10:54 am
> To: "Alex Buckley" <[hidden email]>,
> [hidden email]
>
> Yeah. Sorry about that. I don't know what's going on. But only seconds
> after I pushed my change up to my forked gradle/gradle repo yesterday,
> for some reason github.com flashed an angry red „Your account has been
> flagged. Please contact support...“ message on every page I visit on
> github. I contacted github.com support several hours ago. But they still
> haven't replied.
>
> They've disappeared from Gradle's issue page. They're titled
> „Compliance with Groovy 2.5's Standard Mechanism...“ and
> „Compliance with the JDK's Standard Mechanism...“. I can only see
> them — with the „...flagged...“ message emblazoned across the top
> — when I'm logged into github.com.
>
> I was afraid something like this would happen. So shortly after I first
> submitted the Groovy one, I saved it on the Wayback Machine [1] Stuff
> like this isn't good for that conspiracy theorist in me ;)
>
>
> ----
>
> [1] http://bit.ly/11028bak
>
> ----
>
>
> -------- Original Message --------
> Subject: Re:__Unable_to_derive_module_descriptor_for _gradle-api-5
> .6.2.jar_—_Provider_class_module Name=model-core_n_ot_in_module
> From: Alex Buckley <[hidden email]>
> Date: Tue, October 15, 2019 8:50 am
> To: [hidden email]
>
> On 10/14/2019 9:07 PM, Plugins wrote:
>> I've reported to Gradle's issue tracking system, both the
>> java.security.Provider configuration file issue [1] and the
>> org.codehaus.groovy.runtime.ExtensionModule configuration file issue [2].
>
> Thanks very much. Strangely, AFAICT, the two issues you submitted have
> disappeared -- they return 404 errors, and do not appear in the issue
> list:
>
> http://bit.ly/Issue11027
> -> https://github.com/gradle/gradle/issues/11027
>
> http://bit.ly/Issue11028
> -> https://github.com/gradle/gradle/issues/11028
>
> Alex
>
>