> ... > 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.bate...@oracle.com> Date: Sat, October 12, 2019 12:45 am To: Plugins <plug...@lingocoder.com>, jigsaw-dev@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
