From plugins at lingocoder.com Fri Oct 11 22:41:46 2019 From: plugins at lingocoder.com (Plugins) Date: Fri, 11 Oct 2019 15:41:46 -0700 Subject: Unable to derive module descriptor for gradle-api-5.6.2.jar =?UTF-8?Q?=E2=80=94=20Provider=20class=20moduleName=3Dmodel-core=20not=20?= =?UTF-8?Q?in=20module?= Message-ID: <20191011154146.b6ff8ab09a6c540215cae158a90d7e03.ca2f0dcf85.wbe@email17.godaddy.com> 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 From alex.buckley at oracle.com Fri Oct 11 23:52:13 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 11 Oct 2019 16:52:13 -0700 Subject: =?UTF-8?Q?Re=3a_Unable_to_derive_module_descriptor_for_gradle-api-5?= =?UTF-8?Q?=2e6=2e2=2ejar_=e2=80=94_Provider_class_moduleName=3dmodel-core_n?= =?UTF-8?Q?ot_in_module?= In-Reply-To: <20191011154146.b6ff8ab09a6c540215cae158a90d7e03.ca2f0dcf85.wbe@email17.godaddy.com> References: <20191011154146.b6ff8ab09a6c540215cae158a90d7e03.ca2f0dcf85.wbe@email17.godaddy.com> Message-ID: <5e0ea4c4-d0a6-028b-da5f-162e7f0e3df5@oracle.com> 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 From Alan.Bateman at oracle.com Sat Oct 12 07:45:33 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 12 Oct 2019 08:45:33 +0100 Subject: =?UTF-8?Q?Re=3a_Unable_to_derive_module_descriptor_for_gradle-api-5?= =?UTF-8?Q?=2e6=2e2=2ejar_=e2=80=94_Provider_class_moduleName=3dmodel-core_n?= =?UTF-8?Q?ot_in_module?= In-Reply-To: <20191011154146.b6ff8ab09a6c540215cae158a90d7e03.ca2f0dcf85.wbe@email17.godaddy.com> References: <20191011154146.b6ff8ab09a6c540215cae158a90d7e03.ca2f0dcf85.wbe@email17.godaddy.com> Message-ID: <213fec3c-3de1-6f35-0d7d-7f3d6751df0c@oracle.com> 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 From plugins at lingocoder.com Sat Oct 12 17:41:23 2019 From: plugins at lingocoder.com (Plugins) Date: Sat, 12 Oct 2019 10:41:23 -0700 Subject: Unable to derive module descriptor for gradle-api-5 .6.2.jar =?UTF-8?Q?=E2=80=94=20Provider=20class=20moduleName=3Dmodel-core=20not=20?= =?UTF-8?Q?in=20module?= Message-ID: <20191012104123.b6ff8ab09a6c540215cae158a90d7e03.d7477d9687.wbe@email17.godaddy.com> 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 Date: Fri, October 11, 2019 16:45 pm To: Plugins , 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 From blackdrag at gmx.org Sat Oct 12 19:26:21 2019 From: blackdrag at gmx.org (Jochen Theodorou) Date: Sat, 12 Oct 2019 21:26:21 +0200 Subject: =?UTF-8?Q?Re=3a_Unable_to_derive_module_descriptor_for_gradle-api-5?= =?UTF-8?Q?=2e6=2e2=2ejar_=e2=80=94_Provider_class_moduleName=3dmodel-core_n?= =?UTF-8?Q?ot_in_module?= In-Reply-To: <20191011154146.b6ff8ab09a6c540215cae158a90d7e03.ca2f0dcf85.wbe@email17.godaddy.com> References: <20191011154146.b6ff8ab09a6c540215cae158a90d7e03.ca2f0dcf85.wbe@email17.godaddy.com> Message-ID: <4d0b3ce5-ec92-4fdc-39bb-a30e75f34a71@gmx.org> 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 From alex.buckley at oracle.com Mon Oct 14 16:37:03 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 14 Oct 2019 09:37:03 -0700 Subject: =?UTF-8?Q?Re=3a_Unable_to_derive_module_descriptor_for_gradle-api-5?= =?UTF-8?Q?=2e6=2e2=2ejar_=e2=80=94_Provider_class_moduleName=3dmodel-core_n?= =?UTF-8?Q?ot_in_module?= In-Reply-To: References: <20191011154146.b6ff8ab09a6c540215cae158a90d7e03.ca2f0dcf85.wbe@email17.godaddy.com> <5e0ea4c4-d0a6-028b-da5f-162e7f0e3df5@oracle.com> Message-ID: <8f95b8eb-13d0-26ce-4353-46cc0a3db444@oracle.com> 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 > 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 > From alex.buckley at oracle.com Mon Oct 14 18:56:32 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 14 Oct 2019 11:56:32 -0700 Subject: Using ServiceLoader with modules Message-ID: <9c06c5a0-bfd1-da8a-dc42-c239180fa4f7@oracle.com> I came across a recent blog entry about using ServiceLoader in a modular environment: https://blog.frankel.ch/migrating-serviceloader-java-9-module-system/ Unfortunately, it is completely wrong in its advice on "Migrating to the Java Platform Module System". I have seen the same bad advice on StackOverflow, so let me correct it here, as simply as possible: 1. The module containing the implementation SHOULD NOT export the implementation package. 2. The module containing the client MUST say that it uses the service interface. See the "Deploying service providers as modules" section of https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/util/ServiceLoader.html The whole point of integrating ServiceLoader with the module system was get the configuration documented explicitly, via `uses` and `provides` clauses. Benefits: the implementation is strongly encapsulated (no `exports`), and the client's service lookup is speedy because its dependency (`uses`) was found cheaply during startup. Eventually, as the blog rightly says, "only the configuration changes: the Service Loader code itself in the client doesn?t change." Alex From alex.buckley at oracle.com Mon Oct 14 20:58:08 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 14 Oct 2019 13:58:08 -0700 Subject: Using ServiceLoader with modules In-Reply-To: References: <9c06c5a0-bfd1-da8a-dc42-c239180fa4f7@oracle.com> Message-ID: // cc'ing the list because best practices should be public, and // because it's easier to refer people to it in five years time Hi Christian, On 10/14/2019 12:16 PM, Christian Stein wrote: > ?just read your mail and was wondering if this extrapolation is correct: > > ? ?A module that does not export any package should never need to > ? ?declare a "requires" as transitive. Some qualification needed, I think. There are (at least) two kinds of "top level" module that commonly have no `exports` clauses: 1. An "application module" intended to be launched (`java -m bizapp`) rather than programmed against. I agree that this kind of module should not use `requires transitive`. 2. An "aggregator module" intended to present a facade composed from the APIs of other modules. For example, the `java.se` module has no `exports`, but makes good use of `requires transitive`. (See http://hg.openjdk.java.net/jdk/jdk/file/tip/src/java.se/share/classes/module-info.java.) > For?example, I should remove all `transitive` modifiers from this module > > module org.junit.platform.console { > ? requires transitive org.apiguardian.api; > ? requires transitive org.junit.platform.reporting; > ? provides java.util.spi.ToolProvider > ? ? ? with org.junit.platform.console.ConsoleLauncherToolProvider; > } This "console" module certainly looks like #1 rather than #2. Alex From plugins at lingocoder.com Tue Oct 15 04:07:46 2019 From: plugins at lingocoder.com (Plugins) Date: Mon, 14 Oct 2019 21:07:46 -0700 Subject: =?UTF-8?Q?=5FUnable=5Fto=5Fderive=5Fmodule=5Fdescriptor=5Ffor=5Fgradl?= =?UTF-8?Q?e-api-=35=20=2E=36=2E=32=2Ejar=5F=E2=80=94=5FProvider=5Fclass?= =?UTF-8?Q?=5FmoduleName=3Dmodel-core=5Fn=20ot=5Fin=5Fmodule?= Message-ID: <20191014210746.b6ff8ab09a6c540215cae158a90d7e03.71975eb00a.wbe@email17.godaddy.com> From plugins at lingocoder.com Tue Oct 15 04:16:08 2019 From: plugins at lingocoder.com (Plugins) Date: Mon, 14 Oct 2019 21:16:08 -0700 Subject: Unable to derive module descriptor for gradle-api-5 .6.2.jar =?UTF-8?Q?=E2=80=94=20Provider=20class=20moduleName=3Dmodel-core=20not=20?= =?UTF-8?Q?in=20module?= Message-ID: <20191014211608.b6ff8ab09a6c540215cae158a90d7e03.33eaceafb4.wbe@email17.godaddy.com> From alex.buckley at oracle.com Tue Oct 15 15:50:57 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 15 Oct 2019 08:50:57 -0700 Subject: =?UTF-8?Q?Re=3a_=5fUnable=5fto=5fderive=5fmodule=5fdescriptor=5ffor?= =?UTF-8?B?X2dyYWRsZS1hcGktNSAuNi4yLmphcl/igJRfUHJvdmlkZXJfY2xhc3NfbW9kdWxl?= =?UTF-8?Q?Name=3dmodel-core=5fn_ot=5fin=5fmodule?= In-Reply-To: <20191014210746.b6ff8ab09a6c540215cae158a90d7e03.71975eb00a.wbe@email17.godaddy.com> References: <20191014210746.b6ff8ab09a6c540215cae158a90d7e03.71975eb00a.wbe@email17.godaddy.com> Message-ID: 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 From plugins at lingocoder.com Tue Oct 15 17:54:14 2019 From: plugins at lingocoder.com (Plugins) Date: Tue, 15 Oct 2019 10:54:14 -0700 Subject: Unable to derive module descriptor for gradle-api-5 .6.2.jar =?UTF-8?Q?=E2=80=94=20Provider=20class=20module=20Name=3Dmodel-core=20not?= =?UTF-8?Q?=20in=20module?= Message-ID: <20191015105414.b6ff8ab09a6c540215cae158a90d7e03.ee05cb4832.wbe@email17.godaddy.com> 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 Date: Tue, October 15, 2019 8:50 am To: jigsaw-dev at openjdk.java.net 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 From plugins at lingocoder.com Wed Oct 16 14:21:44 2019 From: plugins at lingocoder.com (Plugins) Date: Wed, 16 Oct 2019 07:21:44 -0700 Subject: Unable to derive module descriptor for gradle-api-5.6.2.jar =?UTF-8?Q?=E2=80=94=20Provider=20class=20moduleName=3Dmodel-core=20not=20?= =?UTF-8?Q?in=20module?= Message-ID: <20191016072144.b6ff8ab09a6c540215cae158a90d7e03.c3897cb9ff.wbe@email17.godaddy.com> 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" Date: Tue, October 15, 2019 10:54 am To: "Alex Buckley" , jigsaw-dev at openjdk.java.net 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 Date: Tue, October 15, 2019 8:50 am To: jigsaw-dev at openjdk.java.net 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 From alex.buckley at oracle.com Wed Oct 16 17:03:17 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 16 Oct 2019 10:03:17 -0700 Subject: =?UTF-8?Q?Re=3a_Unable_to_derive_module_descriptor_for_gradle-api-5?= =?UTF-8?Q?=2e6=2e2=2ejar_=e2=80=94_Provider_class_moduleName=3dmodel-core_n?= =?UTF-8?Q?ot_in_module?= In-Reply-To: <20191016072144.b6ff8ab09a6c540215cae158a90d7e03.c3897cb9ff.wbe@email17.godaddy.com> References: <20191016072144.b6ff8ab09a6c540215cae158a90d7e03.c3897cb9ff.wbe@email17.godaddy.com> Message-ID: 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" > Date: Tue, October 15, 2019 10:54 am > To: "Alex Buckley" , > jigsaw-dev at openjdk.java.net > > 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 > Date: Tue, October 15, 2019 8:50 am > To: jigsaw-dev at openjdk.java.net > > 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 > > From plugins at lingocoder.com Wed Oct 16 22:03:24 2019 From: plugins at lingocoder.com (Plugins) Date: Wed, 16 Oct 2019 15:03:24 -0700 Subject: Preparing to Repair Gradle's Malformed Module Main-Class Command Line Message-ID: <20191016150324.b6ff8ab09a6c540215cae158a90d7e03.1228288713.wbe@email17.godaddy.com> Hi all, Please review this issue [1]? It reports a defect in the Gradle build tool's current construction of malformed java command lines that are intended to execute a Main-Class of a JPMS module. At first I thought the bug reported there was in either the Dropwizard application framework I was using at the time, or in the CLI parser utility (argparse4j) Dropwizard uses under the hood. I am now convinced ? by diagnosis done by those two projects' maintainers ? that the command line construction bug is definitely in Gradle's court. I'd like to request from the list you all's take on this. Please? I have been experimenting with a solution that works so far. But any insight or suggestions anybody here can offer would be muy appreciado! TIA. ---- [1] http://bit.ly/Issue10825 ?Refactor JvmOptions.getAllImmutableJvmArgs() to support executing the main class in a JPMS module? ---- From alex.buckley at oracle.com Wed Oct 16 22:30:56 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 16 Oct 2019 15:30:56 -0700 Subject: Preparing to Repair Gradle's Malformed Module Main-Class Command Line In-Reply-To: <20191016150324.b6ff8ab09a6c540215cae158a90d7e03.1228288713.wbe@email17.godaddy.com> References: <20191016150324.b6ff8ab09a6c540215cae158a90d7e03.1228288713.wbe@email17.godaddy.com> Message-ID: I was going to ask if setting `jvmArgs` in the `run` task is the right way to configure Gradle, but I see it's done here: https://guides.gradle.org/building-java-9-modules/#modify_the_code_run_code_task_to_use_modules Setting aside `-m`: How do you specify the traditional `java -jar myapp.jar` to the `run` task? If it's by setting `jvmArgs` then presumably the same problem occurs of stray arguments being passed to the main class? BTW your module path doesn't need to spell out the JAR file. Just `build/libs` is enough for the Java compiler and the Java runtime to find `my.module`. A module path option should be orders of magnitude shorter than a class path option! Alex On 10/16/2019 3:03 PM, Plugins wrote: > Hi all, > > > Please review this issue [1]? It reports a defect in the Gradle build > tool's current construction of malformed java command lines that are > intended to execute a Main-Class of a JPMS module. > > At first I thought the bug reported there was in either the Dropwizard > application framework I was using at the time, or in the CLI parser > utility (argparse4j) Dropwizard uses under the hood. > > I am now convinced ? by diagnosis done by those two projects' > maintainers ? that the command line construction bug is definitely in > Gradle's court. > > I'd like to request from the list you all's take on this. Please? I have > been experimenting with a solution that works so far. But any insight or > suggestions anybody here can offer would be muy appreciado! TIA. > > ---- > > [1] http://bit.ly/Issue10825 ?Refactor > JvmOptions.getAllImmutableJvmArgs() to support executing the main class > in a JPMS module? > > ---- > From plugins at lingocoder.com Wed Oct 16 23:03:27 2019 From: plugins at lingocoder.com (Plugins) Date: Wed, 16 Oct 2019 16:03:27 -0700 Subject: Preparing to Repair Gradle's Malformed Module Main-Class Command Line Message-ID: <20191016160327.b6ff8ab09a6c540215cae158a90d7e03.39bd88fb7f.wbe@email17.godaddy.com> Thanks for replying Alex, > ?...How do you specify the traditional `java -jar > myapp.jar` to the `run` task? If it's by setting `jvmArgs` then > presumably the same problem occurs of stray arguments being passed to > the main class?..? The traditional `java -jar myapp.jar` setting is the same for both cases. But, oddly enough, from what I've observed, if Gradle detects it's just a ?traditional? run, it will prepend everything _before_ the main class. I mentioned that here [1]: >> The peculiar thing about it, is Gradle does add those >> exact same properties to the beginning of the command >> line when they detect it's a regular --classpath command >> and not a --module-path command. Go figure! I'm relatively new to Gradle. But I'm finding that it's full of magical little surprises like that :) > BTW your module path doesn't need to spell out the JAR file. Just > `build/libs` is enough for the Java compiler and the Java runtime to > find `my.module`. A module path option should be orders of magnitude > shorter than a class path option! Awesome tip! Thanks Alex. That's two awesome tips I learned today. TIL also about the (*) for class path elements: >> ?...As a special convenience, a class path element that contains >> a base name of an asterisk (*) is considered equivalent to specifying >> a list of all the files in the directory with the extension .jar or .JAR. >> A Java program can?t tell the difference between the two invocations. >> For example, if the directory mydir contains a.jar and b.JAR, then the >> class path element mydir/* is expanded to A.jar:b.JAR, except that the >> order of JAR files is unspecified...? ---- [1] http://bit.ly/ArgsHmmm ---- -------- Original Message -------- Subject: Re: Preparing to Repair Gradle's Malformed Module Main-Class Command Line From: Alex Buckley Date: Wed, October 16, 2019 3:30 pm To: jigsaw-dev at openjdk.java.net I was going to ask if setting `jvmArgs` in the `run` task is the right way to configure Gradle, but I see it's done here: https://guides.gradle.org/building-java-9-modules/#modify_the_code_run_code_task_to_use_modules Setting aside `-m`: How do you specify the traditional `java -jar myapp.jar` to the `run` task? If it's by setting `jvmArgs` then presumably the same problem occurs of stray arguments being passed to the main class? BTW your module path doesn't need to spell out the JAR file. Just `build/libs` is enough for the Java compiler and the Java runtime to find `my.module`. A module path option should be orders of magnitude shorter than a class path option! Alex On 10/16/2019 3:03 PM, Plugins wrote: > Hi all, > > > Please review this issue [1]? It reports a defect in the Gradle build > tool's current construction of malformed java command lines that are > intended to execute a Main-Class of a JPMS module. > > At first I thought the bug reported there was in either the Dropwizard > application framework I was using at the time, or in the CLI parser > utility (argparse4j) Dropwizard uses under the hood. > > I am now convinced ? by diagnosis done by those two projects' > maintainers ? that the command line construction bug is definitely in > Gradle's court. > > I'd like to request from the list you all's take on this. Please? I have > been experimenting with a solution that works so far. But any insight or > suggestions anybody here can offer would be muy appreciado! TIA. > > ---- > > [1] http://bit.ly/Issue10825 ?Refactor > JvmOptions.getAllImmutableJvmArgs() to support executing the main class > in a JPMS module? > > ---- > From plugins at lingocoder.com Sun Oct 20 21:41:54 2019 From: plugins at lingocoder.com (Plugins) Date: Sun, 20 Oct 2019 14:41:54 -0700 Subject: Unable to derive module descriptor for gradle-api-5 .6.2.jar =?UTF-8?Q?=E2=80=94=20Provider=20class=20moduleName=3Dmodel-core=20not=20?= =?UTF-8?Q?in=20module?= Message-ID: <20191020144154.b6ff8ab09a6c540215cae158a90d7e03.acbfdf69c5.wbe@email17.godaddy.com> > ... > 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 Date: Sat, October 12, 2019 12:45 am To: Plugins , 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 From plugins at lingocoder.com Thu Oct 31 11:53:53 2019 From: plugins at lingocoder.com (Plugins) Date: Thu, 31 Oct 2019 04:53:53 -0700 Subject: From Gradle 6.0-rc-2 Onward, gradle-api-{$version}.jar Is Now A Working Automatic Module Message-ID: <20191031045353.b6ff8ab09a6c540215cae158a90d7e03.c63777a6d3.wbe@email17.godaddy.com> Heads-up! The fixes that make Gradle's generated API JAR a correctly-functioning automatic module have been released with Gradle 6.0-rc-2! [1] The so-called ?shaded? JAR file is not distributed like other Gradle artifacts. Instead, it is generated lazily whenever you're developing a Gradle plugin. It lives at {$GRADLE_USER_HOME}/caches/6.0-rc-2/generated-gradle-jars/gradle-api-6.0-rc-2.jar. Sincere thanks to C?dric Champeau (melix), Sterling Greene (big-guy), Alan Bateman, Jochen Theodorou (blackdrag) and Alex Buckley! --- [1] http://bit.ly/GrdlisAmodule From blackdrag at gmx.org Thu Oct 31 19:13:29 2019 From: blackdrag at gmx.org (Jochen Theodorou) Date: Thu, 31 Oct 2019 20:13:29 +0100 Subject: From Gradle 6.0-rc-2 Onward, gradle-api-{$version}.jar Is Now A Working Automatic Module In-Reply-To: <20191031045353.b6ff8ab09a6c540215cae158a90d7e03.c63777a6d3.wbe@email17.godaddy.com> References: <20191031045353.b6ff8ab09a6c540215cae158a90d7e03.c63777a6d3.wbe@email17.godaddy.com> Message-ID: <02d230b8-3d8c-fc4f-6282-ed7f746cbe7c@gmx.org> I am happy you managed to do it. bye Jochen On 31.10.19 12:53, Plugins wrote: > Heads-up! The fixes that make Gradle's generated API JAR a > correctly-functioning automatic module have been released with Gradle > 6.0-rc-2! [1] > > The so-called ?shaded? JAR file is not distributed like other Gradle > artifacts. Instead, it is generated lazily whenever you're developing a > Gradle plugin. It lives at > {$GRADLE_USER_HOME}/caches/6.0-rc-2/generated-gradle-jars/gradle-api-6.0-rc-2.jar. > > Sincere thanks to C?dric Champeau (melix), Sterling Greene (big-guy), > Alan Bateman, Jochen Theodorou (blackdrag) and Alex Buckley! > > > --- > > > [1] http://bit.ly/GrdlisAmodule >