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

[Plugins]

> ...
> On 11/10/2019 16:45, Plugins wrote: 
> 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 


Hi Alan. FYI. I've discovered the root cause of that problem...


>> ...
>> The root cause of the defects reported in both #10408 [1]
>> and #11027 [2] is previous and current versions of Gradle's
>> incorrect processing of META-INF/services provider
>> configuration files as if they contain only one single service
>> provider implementation. 
>>  
>> In previous and current versions of Gradle, when there are two or
>> more lines in the provider configuration file, Gradle processes them
>> as a single service provider. So, in the #10408 and #11027 instances,
>> the defect produces the effect of „relocating“ only the first service
>> provider implementation listed in the 
>> META-INF/services/java.security.Provider configuration file. 
>> 
>> By effectively ignoring all but the first implementation in the list,
>> second, third, etc, implementations that are listed in the file are never 
>> „relocated“ as expected. The actual provider implementation class 
>> files themselves do actually exist as entries in the generated shaded 
>> JAR file. However, they are effectively non-existent because an 
>> expected „mapping“ process is done only for the very first provider
>> listed in the configuration file.
>> ...


...and I've submitted a pull request for a proposed solution [3]


----

[1] http://bit.ly/Issue10408
[2] http://bit.ly/Issue11027
[3] http://bit.ly/Issue11093

----

-------- Original Message --------
Subject: Re:_Unable_to_derive_module_descriptor_for_gradle-api-5
.6.2.jar_—_Provider_class_moduleName=model-core_n ot_in_module
From: Alan Bateman <Alan.Bateman at oracle.com>
Date: Sat, October 12, 2019 12:45 am
To: Plugins <plugins at lingocoder.com>, jigsaw-dev at openjdk.java.net

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