Re: NB RC-3 Gradle Issues
On 22/11/05 9:09 PM, Scott Palmer wrote: Somewhat related to the issue described already… My project wants to use JDK 19 features. Gradle 7.5.1 wants to run on something older, e.g. JDK 17. I had a similar issue, the IDE used the wrong source version. The problem was fixed, in my case, by explicitly setting the --source or --release in compiler args and a PR that uses compiler args to override. See https://github.com/apache/netbeans/issues/4704 and the associated patch. Perhaps there's a solution for you in there. -ernie I use a java toolchain specification in the Gradle script so Gradle will happily build with JDK 19 while it runs the Gradle daemon on JDK 17. However, for NetBeans to allow JDK 19 features in the editor, I need to tell it in the project settings… In Project Properties, the “Sources” section has a Source/Binary format field that is read-only. I have to change under Build->Compile the JDK. It then tries to set JAVA_HOME to JDK19 when invoking Gradle builds and Gradle 7.5.1 is not happy. Is it possible for the Gradle plugin to figure out the Java toolchain version that Gradle will use in order to set the source compatibility level of the editor? Scott On Nov 5, 2022, at 6:12 AM, Svata Dedic wrote: It would greatly help to also supply a minimal build.gradle that triggers the failure: I've tried to load several of my gradle samples using JDK19 seemingly without any issues. The printed type/method seems as my changes to gradle loading are the culprit: based on the sample I'll be probably able to wrap the internal API calls into better guards. Please run the IDE with the following on the commandline: -J-Dorg.netbeans.modules.gradle.loaders.LegacyProjectLoader.level=400 that should print (a ton of !) additional gradle-nb communication to the log, possibly including the real exception thrown in the daemon. -Svata On 05. 11. 22 8:26, Laszlo Kishalmi wrote: Reverting back to Java 17 or 18 as IDE runtime would be a solution. Though it seems this time we reached too deep into the Gradle internals an got burned. That means you've found a real bug. Would you report it on github? We might be able to do an RC4 for NB-16. Though it is possible that it would be NB-17. [...] On 11/4/22 21:04, Scott Palmer wrote: When I edited netbeans.conf to force NB to run with JDK 17, my project that uses Gradle 7.6-rc-1 via the Gradle wrapper and JDK 19 (via Gradle Java Toolchain support) still claimed that it would not load. The only error message shown is: 'boolean org.gradle.api.internal.provider.ValueSupplier$ExecutionTimeVaue.isFixedValue()’ I had the Gradle settings in NB set to use that fixed path for Gradle and ignore my wrapper settings. It is the path to my Gradle 7.6-RC-1 install, though I don’t need it to be 7.6 to run the Gradle script.. - To unsubscribe, e-mail:dev-unsubscr...@netbeans.apache.org For additional commands, e-mail:dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail:dev-unsubscr...@netbeans.apache.org For additional commands, e-mail:dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: NB RC-3 Gradle Issues
Somewhat related to the issue described already… My project wants to use JDK 19 features. Gradle 7.5.1 wants to run on something older, e.g. JDK 17. I use a java toolchain specification in the Gradle script so Gradle will happily build with JDK 19 while it runs the Gradle daemon on JDK 17. However, for NetBeans to allow JDK 19 features in the editor, I need to tell it in the project settings… In Project Properties, the “Sources” section has a Source/Binary format field that is read-only. I have to change under Build->Compile the JDK. It then tries to set JAVA_HOME to JDK19 when invoking Gradle builds and Gradle 7.5.1 is not happy. Is it possible for the Gradle plugin to figure out the Java toolchain version that Gradle will use in order to set the source compatibility level of the editor? Scott > On Nov 5, 2022, at 6:12 AM, Svata Dedic wrote: > > It would greatly help to also supply a minimal build.gradle that triggers the > failure: I've tried to load several of my gradle samples using JDK19 > seemingly without any issues. > > The printed type/method seems as my changes to gradle loading are the > culprit: based on the sample I'll be probably able to wrap the internal API > calls into better guards. > > Please run the IDE with the following on the commandline: > > -J-Dorg.netbeans.modules.gradle.loaders.LegacyProjectLoader.level=400 > > that should print (a ton of !) additional gradle-nb communication to the log, > possibly including the real exception thrown in the daemon. > > -Svata > > On 05. 11. 22 8:26, Laszlo Kishalmi wrote: >> Reverting back to Java 17 or 18 as IDE runtime would be a solution. Though >> it seems this time we reached too deep into the Gradle internals an got >> burned. That means you've found a real bug. Would you report it on github? >> We might be able to do an RC4 for NB-16. Though it is possible that it would >> be NB-17. > > [...] >> On 11/4/22 21:04, Scott Palmer wrote: >>> When I edited netbeans.conf to force NB to run with JDK 17, my project that >>> uses Gradle 7.6-rc-1 via the Gradle wrapper and JDK 19 (via Gradle Java >>> Toolchain support) still claimed that it would not load. The only error >>> message shown is: >>> >>> 'boolean >>> org.gradle.api.internal.provider.ValueSupplier$ExecutionTimeVaue.isFixedValue()’ >>> >>> I had the Gradle settings in NB set to use that fixed path for Gradle and >>> ignore my wrapper settings. It is the path to my Gradle 7.6-RC-1 install, >>> though I don’t need it to be 7.6 to run the Gradle script.. >>> > > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: NB RC-3 Gradle Issues
See https://github.com/apache/netbeans/issues/4923 > On Nov 5, 2022, at 3:52 PM, Scott Palmer wrote: > > I’m in the process of filing an issue on GitHub and am doing some experiments > to gather more data for the issue to assist with reproducibility… > > Scott > >> On Nov 5, 2022, at 6:12 AM, Svata Dedic wrote: >> >> It would greatly help to also supply a minimal build.gradle that triggers >> the failure: I've tried to load several of my gradle samples using JDK19 >> seemingly without any issues. >> >> The printed type/method seems as my changes to gradle loading are the >> culprit: based on the sample I'll be probably able to wrap the internal API >> calls into better guards. >> >> Please run the IDE with the following on the commandline: >> >> -J-Dorg.netbeans.modules.gradle.loaders.LegacyProjectLoader.level=400 >> >> that should print (a ton of !) additional gradle-nb communication to the >> log, possibly including the real exception thrown in the daemon. >> >> -Svata >> >>> On 05. 11. 22 8:26, Laszlo Kishalmi wrote: >>> Reverting back to Java 17 or 18 as IDE runtime would be a solution. Though >>> it seems this time we reached too deep into the Gradle internals an got >>> burned. That means you've found a real bug. Would you report it on github? >>> We might be able to do an RC4 for NB-16. Though it is possible that it >>> would be NB-17. >> >> [...] On 11/4/22 21:04, Scott Palmer wrote: When I edited netbeans.conf to force NB to run with JDK 17, my project that uses Gradle 7.6-rc-1 via the Gradle wrapper and JDK 19 (via Gradle Java Toolchain support) still claimed that it would not load. The only error message shown is: 'boolean org.gradle.api.internal.provider.ValueSupplier$ExecutionTimeVaue.isFixedValue()’ I had the Gradle settings in NB set to use that fixed path for Gradle and ignore my wrapper settings. It is the path to my Gradle 7.6-RC-1 install, though I don’t need it to be 7.6 to run the Gradle script.. >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org >> For additional commands, e-mail: dev-h...@netbeans.apache.org >> >> For further information about the NetBeans mailing lists, visit: >> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists >> >> >> - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: NB RC-3 Gradle Issues
I’m in the process of filing an issue on GitHub and am doing some experiments to gather more data for the issue to assist with reproducibility… Scott > On Nov 5, 2022, at 6:12 AM, Svata Dedic wrote: > > It would greatly help to also supply a minimal build.gradle that triggers > the failure: I've tried to load several of my gradle samples using JDK19 > seemingly without any issues. > > The printed type/method seems as my changes to gradle loading are the > culprit: based on the sample I'll be probably able to wrap the internal API > calls into better guards. > > Please run the IDE with the following on the commandline: > > -J-Dorg.netbeans.modules.gradle.loaders.LegacyProjectLoader.level=400 > > that should print (a ton of !) additional gradle-nb communication to the log, > possibly including the real exception thrown in the daemon. > > -Svata > >> On 05. 11. 22 8:26, Laszlo Kishalmi wrote: >> Reverting back to Java 17 or 18 as IDE runtime would be a solution. Though >> it seems this time we reached too deep into the Gradle internals an got >> burned. That means you've found a real bug. Would you report it on github? >> We might be able to do an RC4 for NB-16. Though it is possible that it would >> be NB-17. > > [...] >>> On 11/4/22 21:04, Scott Palmer wrote: >>> When I edited netbeans.conf to force NB to run with JDK 17, my project that >>> uses Gradle 7.6-rc-1 via the Gradle wrapper and JDK 19 (via Gradle Java >>> Toolchain support) still claimed that it would not load. The only error >>> message shown is: >>> >>> 'boolean >>> org.gradle.api.internal.provider.ValueSupplier$ExecutionTimeVaue.isFixedValue()’ >>> >>> I had the Gradle settings in NB set to use that fixed path for Gradle and >>> ignore my wrapper settings. It is the path to my Gradle 7.6-RC-1 install, >>> though I don’t need it to be 7.6 to run the Gradle script.. >>> > > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: NB RC-3 Gradle Issues
It would greatly help to also supply a minimal build.gradle that triggers the failure: I've tried to load several of my gradle samples using JDK19 seemingly without any issues. The printed type/method seems as my changes to gradle loading are the culprit: based on the sample I'll be probably able to wrap the internal API calls into better guards. Please run the IDE with the following on the commandline: -J-Dorg.netbeans.modules.gradle.loaders.LegacyProjectLoader.level=400 that should print (a ton of !) additional gradle-nb communication to the log, possibly including the real exception thrown in the daemon. -Svata On 05. 11. 22 8:26, Laszlo Kishalmi wrote: Reverting back to Java 17 or 18 as IDE runtime would be a solution. Though it seems this time we reached too deep into the Gradle internals an got burned. That means you've found a real bug. Would you report it on github? We might be able to do an RC4 for NB-16. Though it is possible that it would be NB-17. [...] On 11/4/22 21:04, Scott Palmer wrote: When I edited netbeans.conf to force NB to run with JDK 17, my project that uses Gradle 7.6-rc-1 via the Gradle wrapper and JDK 19 (via Gradle Java Toolchain support) still claimed that it would not load. The only error message shown is: 'boolean org.gradle.api.internal.provider.ValueSupplier$ExecutionTimeVaue.isFixedValue()’ I had the Gradle settings in NB set to use that fixed path for Gradle and ignore my wrapper settings. It is the path to my Gradle 7.6-RC-1 install, though I don’t need it to be 7.6 to run the Gradle script.. - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: NB RC-3 Gradle Issues
On Sat, 5 Nov 2022 at 07:26, Laszlo Kishalmi wrote: > Well, yes I usually pull Gradle upgrade when it is likely to have a GA > during the RC phase. Unfortunately this is not the case now. > > Also I usually do not upgrade the bundled Gradle tooling libraries with > patch releases, if there is no fix in that area. The tooling shall be > back and forward compatible between Gradle versions to a certain limit. > > Reverting back to Java 17 or 18 as IDE runtime would be a solution. > Though it seems this time we reached too deep into the Gradle internals > an got burned. That means you've found a real bug. Would you report it > on github? We might be able to do an RC4 for NB-16. Though it is > possible that it would be NB-17. This certainly sounds like it might be one to fix for 16, if doable. I didn't see the original email (below) you replied to?! I was planning a thread to discuss scheduling around Gradle post-release. Was happily testing NB16 on JDK 19 until I realised that Gradle didn't work - most of my projects are Maven-based. With JDK release, then Gradle release, it seems like it'll be NB17 before we can fully support running on (or for us, bundling with) JDK 19. Currently that's going to be just a couple of weeks before JDK 20. Is there anything we could change scheduling and/or tooling wise that might improve that? Best wishes, Neil > On 11/4/22 21:04, Scott Palmer wrote: > > I’ve been fiddling around with NB 16 rc-3 on my Mac where I had JDK 19 > > installed. I noticed that regardless of my project settings, NB is using > > Gradle 7.5 for tooling and can’t run on JDK 19 without getting class > > version errors related to running ‘cp_init'. > > > > While seeing if any settings could fix it, I noticed that the drop-down to > > choose a Gradle version shows 7.6-milestone-1 and some 8.0-milestones, but > > it doesn’t show a choice for 7.6-RC-1 (with JDK 19 support). Though it > > appears that wouldn’t address the issue anyway. > > > > I’m wondering if the embedded Gradle version should be bumped to 7.5.1 > > instead of 7.5 at least. I have doubts that Gradle 7.6 will be released > > before NB 16, but using it to get JDK 19 support for Gradle projects in NB > > would be great. > > > > When I edited netbeans.conf to force NB to run with JDK 17, my project that > > uses Gradle 7.6-rc-1 via the Gradle wrapper and JDK 19 (via Gradle Java > > Toolchain support) still claimed that it would not load. The only error > > message shown is: > > > > 'boolean > > org.gradle.api.internal.provider.ValueSupplier$ExecutionTimeVaue.isFixedValue()’ > > > > The message says priority Low, category Warning… but not loading the > > project seems like it should be a bigger deal. However... > > > > The funny thing is that the project does appear to load and build! Though > > when I build it there is a popup message: > > > > "Could not run build action using connection to Gradle installation > > ‘/Users/scott/dev/gradle’” that appears AFTER the build finishes without > > errors, > > > > I had the Gradle settings in NB set to use that fixed path for Gradle and > > ignore my wrapper settings. It is the path to my Gradle 7.6-RC-1 install, > > though I don’t need it to be 7.6 to run the Gradle script.. > > > > > > Regards, > > > > Scott > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: NB RC-3 Gradle Issues
Well, yes I usually pull Gradle upgrade when it is likely to have a GA during the RC phase. Unfortunately this is not the case now. Also I usually do not upgrade the bundled Gradle tooling libraries with patch releases, if there is no fix in that area. The tooling shall be back and forward compatible between Gradle versions to a certain limit. Reverting back to Java 17 or 18 as IDE runtime would be a solution. Though it seems this time we reached too deep into the Gradle internals an got burned. That means you've found a real bug. Would you report it on github? We might be able to do an RC4 for NB-16. Though it is possible that it would be NB-17. On 11/4/22 21:04, Scott Palmer wrote: I’ve been fiddling around with NB 16 rc-3 on my Mac where I had JDK 19 installed. I noticed that regardless of my project settings, NB is using Gradle 7.5 for tooling and can’t run on JDK 19 without getting class version errors related to running ‘cp_init'. While seeing if any settings could fix it, I noticed that the drop-down to choose a Gradle version shows 7.6-milestone-1 and some 8.0-milestones, but it doesn’t show a choice for 7.6-RC-1 (with JDK 19 support). Though it appears that wouldn’t address the issue anyway. I’m wondering if the embedded Gradle version should be bumped to 7.5.1 instead of 7.5 at least. I have doubts that Gradle 7.6 will be released before NB 16, but using it to get JDK 19 support for Gradle projects in NB would be great. When I edited netbeans.conf to force NB to run with JDK 17, my project that uses Gradle 7.6-rc-1 via the Gradle wrapper and JDK 19 (via Gradle Java Toolchain support) still claimed that it would not load. The only error message shown is: 'boolean org.gradle.api.internal.provider.ValueSupplier$ExecutionTimeVaue.isFixedValue()’ The message says priority Low, category Warning… but not loading the project seems like it should be a bigger deal. However... The funny thing is that the project does appear to load and build! Though when I build it there is a popup message: "Could not run build action using connection to Gradle installation ‘/Users/scott/dev/gradle’” that appears AFTER the build finishes without errors, I had the Gradle settings in NB set to use that fixed path for Gradle and ignore my wrapper settings. It is the path to my Gradle 7.6-RC-1 install, though I don’t need it to be 7.6 to run the Gradle script.. Regards, Scott - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
