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
