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

[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 <alex.buckley at oracle.com 
> <mailto:alex.buckley at oracle.com>> 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
>