You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Laszlo Kishalmi <la...@gmail.com> on 2022/11/05 07:26:41 UTC
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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@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
Posted by Scott Palmer <sw...@gmail.com>.
See https://github.com/apache/netbeans/issues/4923
> On Nov 5, 2022, at 3:52 PM, Scott Palmer <sw...@gmail.com> 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 <sv...@gmail.com> 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-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@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
Posted by Scott Palmer <sw...@gmail.com>.
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 <sv...@gmail.com> 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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@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
Posted by Ernie Rael <er...@raelity.com>.
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<sv...@gmail.com> 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-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail:dev-help@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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail:dev-help@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
Posted by Scott Palmer <sw...@gmail.com>.
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 <sv...@gmail.com> 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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@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
Posted by Svata Dedic <sv...@gmail.com>.
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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@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
Posted by Neil C Smith <ne...@apache.org>.
On Sat, 5 Nov 2022 at 07:26, Laszlo Kishalmi <la...@gmail.com> 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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists