RE: 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
3 messages Options
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
Hi Alan,

Thanks for replying.

Myself and other developers are encountering and reporting other
Gradle-related JPMS-development blocking issues similar to the topic of
this thread [4].

Comments like these from Gradle core devs...


>> „...There's no short-term plan to work on jigsaw support, so please don't hold your breath...“ [5]
   
>> „...Your best bet is to look for a community plugin that adds support for Java modules. We don’t have anything built-in yet...“ [6]


...give the impression that the organization is not all that
enthusiastic about making JPMS development easy when building with
Gradle.


> „...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...“


With all the super-advanced, rock star devs at Gradle, it's hard for me
to believe that nobody on that team considered at least some of those
potential issues. Things like that bring out the conspiracy theorist in
me. Innocent whoopsies like misconfiguring the security provider come
off as ways to passively undermine JPMS adoption. That's where I'm
coming from with „Anti-JPMS“.

Whatever Gradle Inc's actual strategic intentions are, because their
build tool is so popular, their apparent lackadaisical, do-nothing
strategy on JPMS has the _practical_ effect of blocking wider JPMS
adoption.

And, of course, Gradle's dedicated Super Fans will take the same
anti-JPMS position. For a lot of those fans, their reasons might not be
based on the practical nor the technical merits of JPMS. But for no
reason other than: „just because Gradle says so“.


----
[4] http://bit.ly/ArgsHmmm 
[5] http://bit.ly/OehmeBreath
[6] http://bit.ly/bigguYet




-------- Original Message --------
Subject: RE: Unable to derive module descriptor for gradle-api-5.6.2.jar

— Provider class moduleName=model-core not in module
From: Alan Bateman <[hidden email]>
Date: Fri, October 11, 2019 16:45 pm
To: Plugins <[hidden email]>, [hidden email]

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

Plugins
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
> ...
> 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 <[hidden email]>
Date: Sat, October 12, 2019 12:45 am
To: Plugins <[hidden email]>, [hidden email]

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