Re: Run Single on a Gradle 'java-library' Project

[Scott Palmer]

FYI.. although this workflow is functional now without adding the
application plugin there is still a warning printed:

> Task :runSingle
runSingle task is deprecated. Inspect your configuration and use just 'run'
task instead of 'runSingle'

Tested with NB 22,Gradle 8.8 JDK 17

Cheers,

Scott


On Wed, Aug 23, 2023 at 10:19 PM Scott Palmer  wrote:

> This was with NB 19-rc5 and the Gradle 8.3 release.
>
> Project has the 'java-library' Gradle plugin applied.
>
> I wanted to quickly try something in a Java library I was making, so I
> wrote a main method and tried to run it by right-clicking on the source
> file in the project tree and selecting Run File. It failed with the
> following:
>
>
> FAILURE: Build failed with an exception.
>
> * What went wrong:
> A problem occurred configuring project ':app'.
> > Could not create task ':app:runSingle'.
>> Could not find "run" task to execute. Please upgrade your
> configuration to use standard run-style tasks instead of deprecated
> runSingle
>
> I don't think this is new with NB 19.
> Adding the 'application' Gradle plugin allowed it to work.  Would it be
> possible to allow this to work for 'java-library' projects?
>
>
> Cheers,
>
> Scott
>

Re: NB 22-rc3 Cursor key movement broken after deleting a block of text in a Java file

[Scott Palmer]

> On May 14, 2024, at 4:57 AM, Simon IJskes - QCG  wrote:
> 
> On 5/12/24 00:12, Scott Palmer wrote:
>> Has anyone else noticed it?  It was happening in NB 21 as well,
>> maybe before that, but I don't know exactly how to reproduce it because
>> it doesn't happen every time.  Basically select a block of lines and hit
>> delete, then cursor up and down just bounce back to the line you were on.
>> Cursor left/right do something weird too, but if you hold them down you
>> can sort of see it making progress.  In both cases it acts kind of like
>> there is still a selection going on the way you see the line highlight.
>> Scott
> 
> what look and feel are you using? on which platform? i tried a single block 
> delete and noticed nothing strange. On Linux/Flatlaf light.
> 
> i'll keep an eye open.
> 
> Gr. Simon

I believe that time was on macOS (intel) with flat LnF. JDK 21.   Sorry, I 
should have included more details.  I’m not 100% certain if I have seen it on 
Linux or Windows, but I have experienced it multiple times on Mac. 

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

NB 22-rc3 Cursor key movement broken after deleting a block of text in a Java file

[Scott Palmer]

Has anyone else noticed it?  It was happening in NB 21 as well,
maybe before that, but I don't know exactly how to reproduce it because
it doesn't happen every time.  Basically select a block of lines and hit
delete, then cursor up and down just bounce back to the line you were on.
Cursor left/right do something weird too, but if you hold them down you
can sort of see it making progress.  In both cases it acts kind of like
there is still a selection going on the way you see the line highlight.

Scott

Re: NB 21-RC2 doesn't have Gradle-8.5

[Scott Palmer]

Gradle 8.6 is released.  Can that make it in?  If not, let's at least test
with it to ensure nothing breaks.

Cheers,

Scott

On Thu, Feb 1, 2024 at 6:08 PM Michael Bien  wrote:

> https://github.com/apache/netbeans/pull/7022
>
> -mbien
>
>
> On 25.01.24 21:20, Ernie Rael wrote:
> > With NB-21-RC2, running on JDK-21,
> > doing: NewProject > JavaWithGradle > JavaClassLibrary
> > And there is the "resolve problems" icon.
> >
> > $ ./gradlew --version
> > Gradle 8.4
> >
> > I thought this would be Gradle-8.5, especially since there was talk
> > with NB-20
> > of waiting for Gradle-8.5.
> >
> > Unlike with NB-20, with NB-21-RC2, manually upgrading to Gradle-8.5 the
> > "resolve problems" goes away, so that's a good thing.
> >
> > There was some discussion of gradle problems with NB-20,
> > In the thread: "Java version: 21 ... not supported by Gradle 8.5"
> > https://lists.apache.org/thread/m4vppqn8ks3b2gqtc1llctm19vwqwwx9
> >
> > One comment in particular
> >
> > > It seems the bootclasspath is set to the runtime
> > > classpath, that means the Java 21 syntax elements would be available in
> > > the editor, but the new API won't.
> >
> > Since manually upgrading to G-8.5 works better with NB 21-RC2, I'm
> > guessing
> > this issue is fixed, but since I don't know any details about it, just
> > checking.
> >
> > -ernie
> >
> >
> > -
> > 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: an unusual error

[Scott Palmer]

I run NB on Amazon’s JDk-17 on my work laptop all the time. I haven’t seen that 
one. I would guess that library requires another that is missing for some 
reason.  
Try using ldd on that file. 

Scott

> On Dec 5, 2023, at 5:35 PM, Michael Bien  wrote:
> 
> have you installed the full JDK or is this some headless variant?
> 
> some linux distributions split the JDK into multiple parts.
> 
> -mbien
> 
> 
>> On 05.12.23 23:31, Laszlo Kishalmi wrote:
>> Do you have that library?
>> 
>> Do you have other X libraries available.
>> 
>> If some of those missing, you might take a chance to pass 
>> |java.awt.headless=true to the JVM|
>> 
>> |
>> |
>> 
>>> On 12/5/23 14:14, Brad Walker wrote:
>>> I'm working on Amazon Linux and encountered a rather unusual error..
>>> 
>>> I really have no idea about this. Could someone possibly provide some
>>> insight?
>>> 
>>> Maybe a piece of code is trying to load the libawt_xawt.so library?
>>> 
>>> Thanks.
>>> 
>>> -brad w.
>>> 
>>> . . .
>>> files-init:
>>> 
>>> jdk-8-check:
>>> 
>>> -do-set-buildnumber:
>>> 
>>> set-buildnumber:
>>> 
>>> -define-custom-javac-task:
>>> 
>>> -init-compile-bootclasspath-nb:
>>> 
>>> -init-bootclasspath-prepend-compile:
>>> 
>>> -init-bootclasspath-prepend-run8:
>>> 
>>> -init-bootclasspath-prepend-run9:
>>> 
>>> -init-bootclasspath-prepend-run:
>>> 
>>> -init-bootclasspath-prepend:
>>> 
>>> -load-module-flags:
>>> 
>>> build-init:
>>> [parseprojectxml] Distilling
>>> /local/home/walkrzu/src/netbeans/nbbuild/build/public-package-jars/org-openide-io.jar
>>> from
>>> [/local/home/walkrzu/src/netbeans/nbbuild/netbeans/platform/modules/org-openide-io.jar]
>>> [parseprojectxml] Distilling
>>> /local/home/walkrzu/src/netbeans/nbbuild/build/public-package-jars/org-openide-loaders.jar
>>> from
>>> [/local/home/walkrzu/src/netbeans/nbbuild/netbeans/platform/modules/org-openide-loaders.jar]
>>> 
>>> -javac-init-nbjdk:
>>> 
>>> -javac-init-bootclasspath-prepend:
>>> 
>>> -javac-init-no-bootclasspath-prepend:
>>> 
>>> -javac-init:
>>> 
>>> -init-proxy:
>>> 
>>> init:
>>> 
>>> -prepare-mandatory-files-for-module:
>>>  [mkdir] Created dir:
>>> /local/home/walkrzu/src/netbeans/platform/api.search/build/classes/META-INF
>>> [createlicensesummary] All tests passed
>>> 
>>> up-to-date:
>>> 
>>> -pre-compile:
>>> 
>>> -do-compile:
>>>   [nb-javac] Compiling 122 source files to
>>> /local/home/walkrzu/src/netbeans/platform/api.search/build/classes
>>>   [nb-javac] Ignoring source, target and bootclasspath as release has been
>>> set
>>> [repeat]
>>> [repeat]
>>> [repeat] An annotation processor threw an uncaught exception.
>>> [repeat] Consult the following stack trace for details.
>>> [repeat] java.lang.UnsatisfiedLinkError: Can't load library:
>>> /usr/lib/jvm/java-17-amazon-corretto.x86_64/lib/libawt_xawt.so
>>> [repeat] at
>>> java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2398)
>>> [repeat] at java.base/java.lang.Runtime.load0(Runtime.java:755)
>>> [repeat] at java.base/java.lang.System.load(System.java:1953)
>>> [repeat] at java.base/jdk.internal.loader.NativeLibraries.load(Native
>>> Method)
>>> [repeat] at
>>> java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:388)
>>> [repeat] at
>>> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:232)
>>> [repeat] at
>>> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:174)
>>> [repeat] at
>>> java.base/jdk.internal.loader.NativeLibraries.findFromPaths(NativeLibraries.java:315)
>>> [repeat] at
>>> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:285)
>>> [repeat] at
>>> java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2403)
>>> [repeat] at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:818)
>>> [repeat] at java.base/java.lang.System.loadLibrary(System.java:1989)
>>> [repeat] at java.desktop/java.awt.Toolkit$2.run(Toolkit.java:1388)
>>> [repeat] at java.desktop/java.awt.Toolkit$2.run(Toolkit.java:1386)
>>> [repeat] at
>>> java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
>>> [repeat] at
>>> java.desktop/java.awt.Toolkit.loadLibraries(Toolkit.java:1385)
>>> [repeat] at java.desktop/java.awt.Toolkit.initStatic(Toolkit.java:1423)
>>> [repeat] at java.desktop/java.awt.Toolkit.(Toolkit.java:1397)
>>> [repeat] at java.desktop/java.awt.AWTEvent.(AWTEvent.java:266)
>>> [repeat] at
>>> java.base/jdk.internal.misc.Unsafe.ensureClassInitialized0(Native Method)
>>> [repeat] at
>>> java.base/jdk.internal.misc.Unsafe.ensureClassInitialized(Unsafe.java:1155)
>>> [repeat] at
>>> java.base/jdk.internal.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:42)
>>> [repeat] at
>>> java.base/jdk.internal.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:185)
>>> [repeat] at
>>> 

Re: [HELP WANTED] Testing new macOS installer

[Scott Palmer]

Working fine on macOS 13.6.1. (Intel iMac 2017, w. JDK 21 Zulu)

Scott

Re: Gradle project loading issue with NB 20-rc3

[Scott Palmer]

https://github.com/apache/netbeans/issues/6674

On Wed, Nov 8, 2023 at 7:38 PM Laszlo Kishalmi 
wrote:

> This would be better if reported on GitHub as an issue. Attachments
> works there.
>
>
> On 11/8/23 15:35, Scott Palmer wrote:
> > This project was loading on 20-rc3 before, I'm not sure what caused
> > the current problems, but NB doesn't like it anymore and it won't tell
> > me why.  Resolve project problems shows the attached empty problem
> dialog:
> > image.png
> > messages.log didn't offer a clue.
> > The project still seems to work in the IDE though.  I can build
> > without errors. NB just complains that it can't open it, even though
> > it seems to anyway.
> > Many other Gradle projects are still loading fine.  I deleted the
> > cache folder and it didn't help.  I still get that error message for
> > that one project when I startup NB.
> > Using Gradle 8.4, Java 17.
> >
> > Regards,
> >
> > Scott
> >

Gradle project loading issue with NB 20-rc3

[Scott Palmer]

This project was loading on 20-rc3 before, I'm not sure what caused the
current problems, but NB doesn't like it anymore and it won't tell me why.
Resolve project problems shows the attached empty problem dialog:
[image: image.png]
messages.log didn't offer a clue.
The project still seems to work in the IDE though.  I can build without
errors. NB just complains that it can't open it, even though it seems to
anyway.
Many other Gradle projects are still loading fine.  I deleted the cache
folder and it didn't help.  I still get that error message for that one
project when I startup NB.
Using Gradle 8.4, Java 17.

Regards,

Scott

Re: Windows 11 Issues - Copy/Paste Failure

[Scott Palmer]

On Tue, Aug 29, 2023 at 10:58 AM Peter Hull  wrote:

> On Tue, 29 Aug 2023 at 14:59, Scott Palmer  wrote:
> >  But when I worked on Windows it happened all the time.  It was a weekly
> > annoyance.
> >
> I know how frustrating this must be. I use NetBeans on Windows
> (currently NB 18 and Windows 11) and I do not see this issue. In the
> linked bug, there is some code which uses Robot to automate copy/paste
> to notepad, which was said to be a reliable reproducer. But I still
> couldn't get it to go wrong, even running it multiple times.
> The only thing I can say (and I'm sure it's been mentioned before,
> don't hate me) is that I have previously seen clipboard issues when
> VirtualBox was running. So I suppose the question is - are those
> people experiencing it absolutely sure they're not running something
> else that might be interfering with the clipboard?
> Pete
>

I wasn't running VirtualBox, but even so, it's only NetBeans.  Cut and
paste is working between everything else on the system, it is only when NB
is involved that I see issues.  It seems sometimes NB has it's internal
clipboard and doesn't talk to the system clipboard until you do something
to coax it back to working.  Usually a copy from the About dialog will fix
it, when the editor windows are broken with respect to the clipboard.

Scott

Re: Windows 11 Issues - Copy/Paste Failure

[Scott Palmer]

The last time I looked into it, there seemed to be some workarounds in
NetBeans for ancient Swing clipboard issues that probably don't apply
anymore.  I think NB is doing something weird with the clipboard.

I'm primarily developing on Linux now, so I'm spared from this issue.  But
when I worked on Windows it happened all the time.  It was a weekly
annoyance.

Scott


On Tue, Aug 29, 2023 at 6:03 AM Neil C Smith  wrote:

> On Tue, 29 Aug 2023 at 01:14, Michael Bien  wrote:
> > On 29.08.23 00:50, Kenneth Fogel wrote:
> > > I have mentioned this before, but the situation is getting worse. More
> often than not, I must cut the text, paste the text
> >
> > this issue is tracked here:
> https://github.com/apache/netbeans/issues/3962
> >
> > > I do have a question. How many people actively working on NetBeans do
> this in a Windows rather than Linux or MacOS operating system?
> >
> > I believe most NB maintainers are indeed not using windows as their
> > primary OS, those who are might not be able to reproduce it given that
> > it shows some symptoms of a race condition (but it could be something
> else).
>
> It's not just about who is working on Windows, either, but whether
> they can reproduce the problem.  While my primary development platform
> is Ubuntu, I've got development and testing machines on Windows and
> macOS.  I've tried multiple times to reproduce this, including using
> the automated test in that issue (Ken, please look at that too).  My
> system simply never shows the problem.
>
> I think Michael is right to suggest a race condition is in play here.
> That enabling fine logging mitigates the issue for many would suggest
> timing.  However, the logging also has side effects, which eagerly
> acquires the data in the clipboard, which could also be affecting the
> outcome.
>
> Also, let's not assume that this is unique to NetBeans or even a bug
> in NetBeans itself!  https://youtrack.jetbrains.com/issue/JBR-5980/
>
> Best wishes,
>
> Neil
>
> -
> 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
>
>
>
>

Run Single on a Gradle 'java-library' Project

[Scott Palmer]

This was with NB 19-rc5 and the Gradle 8.3 release.

Project has the 'java-library' Gradle plugin applied.

I wanted to quickly try something in a Java library I was making, so I
wrote a main method and tried to run it by right-clicking on the source
file in the project tree and selecting Run File. It failed with the
following:


FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring project ':app'.
> Could not create task ':app:runSingle'.
   > Could not find "run" task to execute. Please upgrade your
configuration to use standard run-style tasks instead of deprecated
runSingle

I don't think this is new with NB 19.
Adding the 'application' Gradle plugin allowed it to work.  Would it be
possible to allow this to work for 'java-library' projects?


Cheers,

Scott

Observation with Gradle Project on 19-rc5

[Scott Palmer]

(I don't think this is caused by anything new in NB 19)

I had an embarrassing thing happen this morning when we needed to apply a
hotfix at work. (I'm the only one using NetBeans at work)

I had a different branch of the project already loaded, so I closed that
and loaded a different copy of the project.  I quickly made the required
change in NB (removing a couple lines of logging), and then switched to the
command line to fiddle with Git and do the build with Gradle. (I had to add
some custom options to speed up the build for this hotfix so it was quicker
from the command line.)

The code failed to compile with many errors that made no sense.

A colleague took over and finished the hotfix, but I wondered what went
wrong.  It turns out that NB removed imports that were needed when I
saved.  I do want NB to keep my imports in order when I save, but it
mistakenly thought it could get rid of a few imports that it had
highlighted as not being used.

When I merged in the correct change from my colleague, NB still showed
these imports as not needed.  I wondered what I needed to do to convince it
that it was wrong. So I triggered a build of the project from within NB, it
built and tested without issues. I watched to see if the "unused imports"
indicators would go away.  Instead of that happening, it flagged all of the
imports from this project as "missing" and marked all of my source files as
"needs to be compiled" - I just finished compiling them all!!

I expected maybe this would resolve itself in a moment or too after some
sort of scan, but no.  It's stuck thinking all the project classes are
missing, immediately after having just built them all.

So I manually triggered a "Reload Project" and that fixed the errors with
the missing imports, but NB still marked those few required imports as not
being required, and it still shows indicators that every source file needs
to be compiled.
I just then noticed that the package declaration line had a warning saying
"Missing mandatory Classpath entries.  Resolve Project Problems."  NB
thinks I need to do a "Priming Build.  It is true that I didn't do a
priming build after having loaded this branch of the project . I don't
think I was prompted to.  What is most annoying is that I have already
manually triggered a full build from within NB!  That should have resolved
the need for doing a priming build, I clearly trust this build script!

So I take the hint that NB is giving me and it opens the "Resolve Project
Problems" dialog.  I select "Priming Build Required" and press the
"Resolve..." button.  And nothing happens - well the focus changes to the
"Description" panel, and there is a very brief message in the status bar
that says "Preparing  ()", but the problem does
not go away.  Selecting "Reload Project" does nothing as well.

I've attached the tail end of messages.log, in case that might give a hint.

A restart of NB resolved the issue.

This is the sort of experience that makes it hard to convince others how
wonderful NB is :-)

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

Re: [HELP WANTED] Testing new macOS installer

[Scott Palmer]

Meant for the list, but the reply button in Gmail only sends it to the
original poster and I forgot to fix the address.  I think the RC's should
have a different bundle ID and name to prevent accidentally installing over
official versions.

Cheers,

Scott

On Fri, Aug 11, 2023 at 5:07 AM Neil C Smith  wrote:

> Hi,
>
> On Thu, 10 Aug 2023 at 16:33, Scott Palmer  wrote:
> >
> > Worked for me on iMac Retina 5k, 27-inch, 2017
> > 4.2 GHz Quad-Core Intel Core i7
> > Ventura 13.4.1 (22F82)
> >
> > Noticed that it doesn't install in a NetBeans subfolder of Applications
> nor include the version number in the name. which I see was intentional
> based on reading the issue. I have no issue with that, but I think we need
> to make it clear in the release notes - specially if installing a beta or
> RC will overwrite your previous release version!
>
> Thanks for checking!  Was that email meant to be a direct reply to me
> rather than the list?
>
> On the beta / RC question - well, we don't have betas anymore.  And
> we've rarely had a macOS installer for RCs in the past.  Now we have a
> more sustainable way to produce we might do them more frequently.  As
> you can see from the command line in the original post, it's easy to
> specify bundle ID and name, so we can certainly produce isolated
> packages.  A few people in earlier testing had commented they prefered
> in-place upgrading.  We should perhaps consider a secondary bundle ID
> for RC so they can be installed alongside though?  Doing so will also
> differentiate between released and unreleased versions.
>
> Best wishes,
>
> Neil
>

Re: Please Test your Gradle Workflows with NetBeans 19-rc-3

[Scott Palmer]

Yes, the change to a Kotlin default for the build scripts is very
annoying.   You could hardcode the option to use Groovy for now, until the
UI selector is ready.

Scott

On Fri, Aug 4, 2023 at 10:03 PM Laszlo Kishalmi 
wrote:

> Well,
>
> Usually there is not too much change if any on the tooling side between
> the RC-s and the final release of Gradle. The main glitch is that new
> project would be generated using the 8.3-rc-1 as default even after 8.3
> come out.
>
> Also there is another "issue", that from 8.2, Gradle generates Kotlin
> DSL by default, which could be confusing. I do not how big "pain" that
> could be, especially if we consider that we are quite popular in the
> Education sector... A patch to get the Groovy back might would worth
> another RC, might not...
>
> I've plan to add a Gradle DSL dialect selector to the new project page
> later
>
> On 8/4/23 17:00, Scott Palmer wrote:
> > There's no guarantee that there isn't going to be a Gradle 8.3-rc-4 of
> > course.. but I believe they have a policy of letting any RC soak for
> about
> > a week, but maybe shorter depending on what changed since the previous
> RC.
> > There were only a couple days between the last RC for 8.2 and the final
> > release. RC-3 was announced on Wednesday, August 2nd.
> >
> > You and Laszlo can make the call.
> >
> > Cheers,
> >
> > Scott
> >
> >
> > On Fri, Aug 4, 2023 at 2:19 PM Neil C Smith 
> wrote:
> >
> >> On Fri, 4 Aug 2023, 18:53 Scott Palmer,  wrote:
> >>
> >>> Seems to be working well.  I see Gradle 8.3-rc-3 is available, but
> didn't
> >>> make it into NetBeans19-RC4.  I haven't noticed any regressions, so I
> >> would
> >>> try to squeeze in whatever the latest artifact is for Gradle 8.3 when
> the
> >>> final NB 19 build is made.
> >>>
> >> We'd need another NetBeans release candidate for that. Doable. Are the
> >> Gradle RC on a schedule? If so, possibly wait to see if a final release
> is
> >> made soon?
> >>
> >> Best wishes,
> >>
> >> Neil
> >>
>
> -
> 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: Please Test your Gradle Workflows with NetBeans 19-rc-3

[Scott Palmer]

There's no guarantee that there isn't going to be a Gradle 8.3-rc-4 of
course.. but I believe they have a policy of letting any RC soak for about
a week, but maybe shorter depending on what changed since the previous RC.
There were only a couple days between the last RC for 8.2 and the final
release. RC-3 was announced on Wednesday, August 2nd.

You and Laszlo can make the call.

Cheers,

Scott


On Fri, Aug 4, 2023 at 2:19 PM Neil C Smith  wrote:

> On Fri, 4 Aug 2023, 18:53 Scott Palmer,  wrote:
>
> > Seems to be working well.  I see Gradle 8.3-rc-3 is available, but didn't
> > make it into NetBeans19-RC4.  I haven't noticed any regressions, so I
> would
> > try to squeeze in whatever the latest artifact is for Gradle 8.3 when the
> > final NB 19 build is made.
> >
>
> We'd need another NetBeans release candidate for that. Doable. Are the
> Gradle RC on a schedule? If so, possibly wait to see if a final release is
> made soon?
>
> Best wishes,
>
> Neil
>

Re: Please Test your Gradle Workflows with NetBeans 19-rc-3

[Scott Palmer]

Seems to be working well.  I see Gradle 8.3-rc-3 is available, but didn't
make it into NetBeans19-RC4.  I haven't noticed any regressions, so I would
try to squeeze in whatever the latest artifact is for Gradle 8.3 when the
final NB 19 build is made.

Scott


On Fri, Jul 28, 2023 at 11:02 AM Laszlo Kishalmi 
wrote:

> Dear all,
>
> Gradle 8.3-rc1 came very late in the game, but it is the one which
> finally supports JDK 20 as runtime. That's why we dropped that in.
> Please test!
>
>
> Thanks!
>
> --
>
> Laszlo Kishalmi
>

Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)

[Scott Palmer]

On Mon, Apr 10, 2023 at 1:41 PM Svata Dedic 
wrote:

> On 10. 04. 23 19:35, Scott Palmer wrote:
> > Note that the one example we have been given so far of "Microchip IDE",
> if
> > it is what I think it is "MPLAB X IDE" (
> > https://www.microchip.com/en-us/tools-resources/develop/mplab-x-ide),
> then
> > it seems to have Windows 10, Ubuntu 16.04, macOs 10.15 as minimums.  Java
> > 11 runs on those platforms, and a JRE has been distributed with the
> product
> > since 5.40.  So I continue to search for a real case for Java 8 support.
>
> Minor correction: the actually distributed JRE is:
> OpenJDK Runtime Environment (Zulu 8.64.0.19-CA-linux64) (build
> 1.8.0_345-b01)
>
> -S.
>

I didn't mean to suggest the distributed JRE was currently Java 11.  I
implied that it could easily be Java 11.  I.e. moving to Java 11 seems to
not be an issue.  Azul's OpenJDK build of JDK 11 has the same license terms
I believe.

Scott

Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)

[Scott Palmer]

Just to be clear, there is no "hate" on my part.  I know the "tone" is hard
to communicate via email.  I just disagree that Java 8 support should
continue in the main codebase.
When I suggest that a Java 8 compatible fork is how to proceed, I wish you
all the best of success with it.  If you have that need I see no reason why
you shouldn't be able to pursue it.

I don't see the case for Java 8 going forward with new NB releases, and I
disagree that that main code should be muddied with any "ifs" to support
Java 8.  I just don't see that it is worth it.  In fact I see it as a net
negative to keep dragging out the life of Java 8.  We should
actively promote moving forward rather than staying in the past.  Draw the
line, maintain a Java 8 fork if necessary, keep the rest of the code Java
11+ with a policy that is clear about when that support will no longer be
guaranteed and how the minimum version is decided. Clean and simple.

This is particularly important for an open source project that needs to
attract developers.  Nobody *wants* to maintain ancient code.

Note that the one example we have been given so far of "Microchip IDE", if
it is what I think it is "MPLAB X IDE" (
https://www.microchip.com/en-us/tools-resources/develop/mplab-x-ide), then
it seems to have Windows 10, Ubuntu 16.04, macOs 10.15 as minimums.  Java
11 runs on those platforms, and a JRE has been distributed with the product
since 5.40.  So I continue to search for a real case for Java 8 support.


Scott

On Mon, Apr 10, 2023 at 12:46 PM Jaroslav Tulach 
wrote:

> Thank you Sváťa for writing this email. It open another "can of worms" in
> the "lazy consensus" thread - in my opinion clearly rendering the "lazy
> consensus" as obsolete.
>
> I still need a bit of time to think about using your email strategically,
> but in any case I'm happy. I am no longer the only one who gets all the
> hater!
>
> Thank you Sváťo!
> -jt
>
> ...
>

Re: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)

[Scott Palmer]

As far as basing decisions on actual data goes, I agree completely.  Do we have 
any data on how many users would be affected by dropping JDK 8 support in 
future NetBeans versions?  I’m talking real numbers here, not a few people 
stating, “I would like it to run on Java 8”.

That is:
- How many users are on a platform that can’t run Java 11 (either due to 
technical issues or company policies)?
- How many users NEED to move to a future NB platform? (The answer must be 
zero, as they don’t even know what the future NB platform offers at the moment.)

Those are the users that should be counted, and I haven’t seen any data on how 
big that set of users is relative to the entire NB user base.  Those proposing 
continued Java 8 support need to supply this data to validate their argument.

My gut instinct is that there are very few users that fit that criteria, and 
those that do could be supported by the few developers that have volunteered to 
keep Java 8 working.

Mind you, I also think that if there is data suggesting that this subset of 
users is significant, then it also suggests that they might have the resources 
to support a Java 8 fork and allow the mainstream NB to not be anchored in the 
past. IMO dropping Java 8 support is a few years overdue already.

I do laugh at the idea of Window XP support though. Windows XP was EOL 9 years 
ago.  It is absurd to suggest continued support for it in NB. Have we learned 
nothing from the ridiculous limitations imposed by DOS that are still present 
in Windows 11? I’ve seen a few Java projects fail to build because of those 
limitations.  That’s what clinging to backwards compatibility for too long gets 
you.


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

Re: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)

[Scott Palmer]

+1
Java 8 LTS technically ended a year ago (with “extended” support available 
until 2030).
Android shouldn’t be the boat anchor holding NB back. (Android isn’t even a 
supported platform for Java 8. 
https://www.oracle.com/java/technologies/javase/products-doc-jdk8-jre8-certconfig.html)

There is nothing stopping those that want to maintain a Java 8 compatible port 
of NB, but there is no justification to inflict the “suffering” on the future 
development of the main NB project. Specially without metrics to demonstrate a 
demand for the requirement. Attracting contributors is hard enough. 

Scott

> On Apr 5, 2023, at 4:33 PM, John Kostaras  wrote:
> 
> -1
> 
> Java 8 is also LTS and many out there are still stuck to it. I support
> Jarda, too.
> 
>> On Wed, Apr 5, 2023 at 6:25 PM toni.ep...@eppleton.de <
>> toni.ep...@eppleton.de> wrote:
>> 
>> -1
>> 
>> I agree with Jarda. Having the portability for platforms like Android is
>> important, and I support the proposed alternative.
>> 
>> 
>> 
>> Von: Jaroslav Tulach 
>> Datum: Mittwoch, 5. April 2023 um 17:13
>> An: dev 
>> Betreff: Re: [Lazy Consensus] Minimum JDK build and run policy (dropping
>> JDK 8)
>> -1
>> 
>> Background: http://wiki.apidesign.org/wiki/Portability
>> 
>> 
>> Alternative:
>> 
>> - I will maintain what ever needs to be maintained to keep JDK 8 CI tests
>> running
>> 
>> - From Apache NetBeans 19, the minimum JDK required to build and run
>> the IDE will be JDK 11.
>> 
>> - The minimum JDK to run and test the NetBeans Platform and modules up to
>> VSCode & Jackpot remains JDK 8.
>> 
>> - Usage of JDK11, JDK17, etc. API is possible in dedicated modules via
>> http://
>> wiki.apidesign.org/wiki/AlternativeImplementation
>> 
>> 
>> Justification:
>> 
>> Writing in Java (a language designed to write once and run everywhere)
>> greatly
>> increases portability. However there is another axis hurting portability -
>> the
>> supported JDK version. Of course, should a library be widely used, it has
>> to
>> support as oldest JDK as possible. These days it is JDK8 - the primary
>> reason
>> being that Android supports JDK8 - as such, should a library aspire to be
>> used
>> on Android (as well as regular Java), it needs to stick to version eight.
>> 
>> There's transitivity of non-portability - the portability of the final
>> application cannot be bigger than portability of the least portable library
>> used. This applies also to 3rd party dependencies a framework or library
>> has:
>> again their non-portability may negatively affect portability of such
>> framework
>> or library.
>> 
>> Of course, writing portable libraries is harder. It requires more work from
>> the API author, more self-control, more suffering. However such suffering
>> is
>> justifiable. There is usually a single API writer, but there are many
>> users to
>> it. What matters is to simplify and improve experience of those API users -
>> own author suffering doesn't matter that much.
>> 
>>> # Proposed policy
>>> 
>>> * Apache NetBeans 18 will be the last release to support running the
>>> platform on JDK 8.
>>> 
>>> * From Apache NetBeans 19, the minimum JDK required to build and run
>>> the IDE or platform will be JDK 11.
>>> 
>>> * Future releases will take an "LTS-1" strategy for building and
>>> running (and CI testing) of the IDE and platform. Three JDKs will be
>>> supported at any one time - the current JDK, plus the previous two LTS
>>> releases. eg. NetBeans 20 and 21 (Nov 2023 / Feb 2024) will support
>>> JDK 11, 17 and 21. NetBeans 22 (May 2024) will support JDK 17, 21 and
>>> 22.
>>> 
>>> ## Background
>>> 
>>> The Apache NetBeans IDE has officially required JDK 11 to build and
>>> run since NetBeans 13 in March 2022. The platform (and unofficially
>>> the IDE) have continued to support running on JDK 8 - all modules
>>> requiring a higher JDK must currently be optional. Various tests have
>>> continued on JDK 8.
>>> 
>>> This situation is causing issues as workarounds must be found for
>>> currently non-optional features that have dependencies or other
>>> requirements for running on a higher JDK (eg. Maven indexing / Lucene
>>> [1]). It's causing delays, complications and missed testing time in
>>> integration of new features (eg. problems merging support for EE 10
>>> [2]). Supporting an increasing range of JDKs is causing increasing
>>> workload, both for people and CI. Meeting the challenges of deprecated
>>> (for removal) features in the JDK is also complicated by the
>>> additional JDK requirements.
>>> 
>>> ## Notes
>>> 
>>> * Apache NetBeans users will continue to be recommended to use the
>>> current or latest LTS JDK to run the IDE.  The IDE will continue to
>>> support users developing projects for/with JDK 8, for as long as
>>> nb-javac and other dependencies allow.
>>> 
>>> * This proposal specifically doesn't address when the default bytecode
>>> level across the codebase is increased. This can happen when required,
>>> but non-optional modules 

Re: Lets talk about JDK 8 (new year edition)

[Scott Palmer]

On Sun, Apr 2, 2023 at 9:38 AM Jaroslav Tulach 
wrote:

> > >> https://github.com/apache/netbeans/issues/4904
> > >>
> > >> see also 'priority:high' label for more,
> > >
> > > The issue says "Many tests fail on JDK 11" - how does that compare to
> JDK
> > > 8?
> > well. You mostly see this while trying to fix them. It always requires
> > extra work to keep supporting 8 too.
>
> The "extra work" is "keeping the code that already works"! We have code
> that
> works on JDK8 and there is no "extra work" to let it run on JDK8! Adding
> one
> additional `if (JDK11+)` check and writing new code is the "extra work",
> but
> it has nothing to do with supporting JDK8!
>

No, it's keeping ancient code that works kludged into a system that
desperately wants to move on.
The one line "if" isn't the problem, it's making sure the code in the body
of that if and the code in the "else" coexisting without problems.

Let's face it, the "code that already works" is NetBeans 17.  The "if" is
simple. IF you want to run on JDK 8, use NetBeans 17.
There has yet to be any justification presented to keep future versions
working on JDK 8.  Why should we be writing software for over 6 years ago
instead of software for today and tomorrow?


> > > I am a guy who cares about compatibility (of NetBeans): Please tell me
> if
> > > there is a test that doesn't work on JDK 8 and needs to be fixed.
>
> I am still willing to maintain JDK8 tests, CI & etc.
>

Okay.  Then maintain your own branch that works on JDK 8 and let the main
NetBeans code move on.


> > With every new JDK release it will become more difficult to keep
> > supporting JDK 8 as runtime.
>
> No. That is not true. The code exists and works. You don't have to do
> anything
> special to continue support it.
>

No. That is not true.  The burden to keep JDK 8 code working *while the
world around that code changes* is significant.
E.g if we chose to use a Record for something that needs to pass through a
JDK 8 compatible code path, what then?

>
> > It also becomes increasingly difficult to
> > motivate myself to fix JDK 8 issues in my freetime.
>
> I can imagine that. However we are not coding NetBeans to please
> ourselves,
> but to please our users. NetBeans Platform users need JDK8 support.


So far you are the only user that has spoken up about wanting (much less
needing) NetBeans to run on JDK 8.
Where are the other users? Why do they need *future* versions of NB on JDK
8 rather than what they are running now? (This has been asked multiple
times and I don't think we've ever got an answer, but I may have missed it.)


> That's why
> I am volunteering to maintain and run the CI & tests on JDK8.
>

And when the tests fail? Are you going to do all the fixes?
If so, how is it different from you personally maintaining a JDK 8
compatible branch of NetBeans?


Sorry,  I'm with Mr. Gosling on this one.  Let JDK 8 die, or rather, as he
put it, "kill it."

Scott

Re: log4j

[Scott Palmer]

I just took a look at the code and there is only one commented out line
that mentions log4j in the html validator code.  "git grep log4j" shows the
string appearing in plenty of other places, but it doesn't look like log4jh
actually gets used anywhere!

Scott

On Thu, Mar 23, 2023 at 9:59 PM Eirik Bakke  wrote:

> Is there any reason to use log4j instead of java.util.logging these days?
> If log4j is only use in one place in the NetBeans codebase, it might be
> beneficial to get rid of it in any case--one less dependency, and fewer
> overlapping logging libraries.
>
> -- Eirik
>
> -Original Message-
> From: Matthias Bläsing 
> Sent: Thursday, March 23, 2023 2:48 PM
> To: dev@netbeans.apache.org
> Subject: Re: log4j
>
> Hi,
>
> Am Donnerstag, dem 23.03.2023 um 09:53 -0400 schrieb William Shackleford:
> > Netbeans appears to include log4j even the most recent version.
> >
> > in
> >
> > netbeans/ide/modules/ext/log4j-1.2.15.jar
> >
> > Our IT security group has flagged it and requires that it be removed
> > even though as it is version 1 it is not vulnerable to the most famous
> > issue as apparently there were other issues  and it is no longer
> supported.
> >
> > What are the consequences of removing it?
>
> If I saw it correctly, log4j is used by the html validator only.
> Anything that calls into that might break. That also might happen
> indirectly.
>
> >
> > How would I go about committing  or just suggestion a change to have
> > it removed from future versions
>
> Have a look at the html.parser and html.validator modules. Both most
> probably need to be updated or might be patched not to carry log4j.
> Patching html.validator might be the quickest way, updates to current
> version might be better in the long run.
>
> The hard
>
> > to avoid triggering our security team from telling everyone to delete
> > it and maybe all of netbeans with it?
>
> The alternative is: Solve organisational problems inside the organisation.
> If the security team indeed has the misconception that "has log4j === is
> vulnerable", than you might need a new security team.
>
> My status on the CVEs:
>
> - CVE-2019-17571: SocketServer needs to be explicitly loaded, we are not
> vulnerable
> - CVE-2020-9488: We don't use the SMTPAppender, we are not vulnerable
> - CVE-2021-4104: We don't use the JMSAppender, we are not vulnerabe
> - CVE-2022-23302: We don't use the JMSSink, we are not vulnerable
> - CVE-2022-23305: We don't use the JDBCAppender, we are not vulnerable
> - CVE-2022-23307: Apache Chainsaw is not used
>
> Greetings
>
> Matthias
>
> -
> 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: Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))

[Scott Palmer]

Some minimum JDK level needs to be specified.  While this is basically
arbitrary based on the needs of the platform and work required to support
it, I think it makes sense that the minimum should be some LTS version.  To
get the widest audience would suggest that version should be the oldest LTS
still supported at the time of release.  That would mean any release prior
to September 2023 should have JDK 11 as the minimum and not anything more
recent.
If that minimum is considered too old for any reason then the next JDK to
consider should be the next LTS release after JDK 11.
Is there an argument for considering non-LTS releases?  I suggest those
primarily because it seems they would be the JDKs most likely to be picked
in general for any arbitrary company, dependency, or whatever.  Releases
between LTS releases are likely to be selected only when they contain a
particular needed feature.
I think it should go without saying that whatever JDK is selected as the
minimum, no incubating or preview features should be used.  That just opens
another can of worms.
At the same time the expectation of users is that NetBeans will support the
current JDK for development. Ideally coding for EA releases should work on
a best-efforts basis.  How are we to evaluate EA releases if our tools
won't support them?  While NB must require some minimum version, it is not
unreasonable to require it to run on a more recent version in order to
support more recent JDKs.  My point being that I don't see an issue if
running NB on JDK 11 means you can't properly work with a project that
needs JDK 19.  If you need to run on JDK 19 to develop for JDK 19, that's
fair.
Personally, I think it is important to make the jump away from JDK 8.  It
matters far less how far that jump is. JDK 11 would perhaps be the least
disruptive option in what is certainly going to be a disruptive transition
for some. But the difference from JDK 11 to JDK 17 is insignificant in
comparison to JDK 8 to 11.  If you're going to break compatibility, why
drag your feet?  Move forward as far as you can and sit there for a while
with a stable target JDK version, rather than tip-toeing one step at a time
trickling a few disruptions in at every release.

My 2c,

Scott

Codeium Plugin?

[Scott Palmer]

I recently tried out the Codeium plugin in VSCode and was very impressed.
See https://codeium.com/ - it's an AI assistant similar to those offered by
GitHub Copilot and TabNine.
But I miss it in my favourite IDE.  I'm not familiar enough with NetBeans
internals to try to integrate it myself, but I wonder if someone on this
list might take on the challenge?
I know from messages on their discord server that they have open-sourced a
plugin for emacs or something like that, so I believe there is a public API
available and reference code.

Cheers,

Scott

How to screw up the NetBeans 17 macOS installer post-install script

[Scott Palmer]

This is just a heads-up to any keeners like me that hack their own app
bundle for the betas...

I had NB 17-rc3 already installed.. I basically had copied the NB 16
application bundle, changed the info.plist so that it claimed to be 17, and
copied the NB 17-rc3 binary zip contents into the appropriate place to hack
together my own Application bundle.  I do that because during the beta
period macOS bundles are not provided.  I named it "Apache NetBeans 17-rc3"
and placed it beside NB 16 in /Applications/NetBeans.  It was working fine.

I just grabbed the .pkg installer for NB 17.  Quit my NB 17-rc3 hacked
version and tried to run the installer.  If seemed to get most of the way
through and then failed with a generic message that said "The installation
failed.  The Installer encountered an error that caused the installation to
fail. Contact the software manufacturer for assistance."

macOS's install.og contains:

2023-02-27 16:08:08-05 iMac installd[616]: PackageKit
(package_script_service): Preparing to execute script "./postinstall" in
/private/tmp/PKInstallSandbox.o8C3yC/Scripts/org.netbeans.postinstallscripts.FFSYTF
2023-02-27 16:08:08-05 iMac package_script_service[67541]: PackageKit:
Preparing to execute script "postinstall" in
/tmp/PKInstallSandbox.o8C3yC/Scripts/org.netbeans.postinstallscripts.FFSYTF
2023-02-27 16:08:08-05 iMac package_script_service[67541]: Set
responsibility to pid: 14510, responsible_path:
/System/Library/CoreServices/Installer.app/Contents/MacOS/Installer
2023-02-27 16:08:08-05 iMac package_script_service[67541]: Hosted team
responsibility for script set to team:(2GLGAFWEQD)
2023-02-27 16:08:08-05 iMac package_script_service[67541]: PackageKit:
Executing script "postinstall" in
/tmp/PKInstallSandbox.o8C3yC/Scripts/org.netbeans.postinstallscripts.FFSYTF
2023-02-27 16:08:08-05 iMac package_script_service[67541]: ./postinstall:
Complete installation /Applications/NetBeans/Apache NetBeans 17.app
2023-02-27 16:08:08-05 iMac package_script_service[67541]: ./postinstall:
Result of populate_caches.sh : 0
2023-02-27 16:08:08-05 iMac package_script_service[67541]: ./postinstall:
/tmp/PKInstallSandbox.o8C3yC/Scripts/org.netbeans.postinstallscripts.FFSYTF/postinstall:
line 46: cd: */Applications/NetBeans/Apache NetBeans 17.app
: No such file or directory*
2023-02-27 16:08:08-05 iMac package_script_service[67541]: PackageKit:
Hosted team responsible for script has been cleared.
2023-02-27 16:08:08-05 iMac package_script_service[67541]: Responsibility
set back to self.
2023-02-27 16:08:08-05 iMac install_monitor[14521]: Re-included:
/Applications, /Library, /System, /bin, /private, /sbin, /usr
2023-02-27 16:08:08-05 iMac installd[616]: PackageKit: releasing backupd
2023-02-27 16:08:08-05 iMac installd[616]: PackageKit: allow user idle
system sleep
2023-02-27 16:08:08-05 iMac installd[616]: PackageKit: Install Failed:
Error Domain=PKInstallErrorDomain Code=112 "An error occurred while running
scripts from the package “Apache NetBeans 17.pkg”."
UserInfo={NSFilePath=./postinstall,
NSURL=file://localhost/Volumes/Apache%20NetBeans%2017/Apache%20NetBeans%2017.pkg#postinstallscripts.pkg,
PKInstallPackageIdentifier=org.netbeans.postinstallscripts,
NSLocalizedDescription=An error occurred while running scripts from the
package “Apache NetBeans 17.pkg”.} {
   NSFilePath = "./postinstall";
   NSLocalizedDescription = "An error occurred while running scripts from
the package \U201cApache NetBeans 17.pkg\U201d.";
   NSURL =
"file://localhost/Volumes/Apache%20NetBeans%2017/Apache%20NetBeans%2017.pkg#postinstallscripts.pkg";
   PKInstallPackageIdentifier = "org.netbeans.postinstallscripts";
}
...
2023-02-27 16:08:09-05 iMac Installer[14510]: 'Install Failed' UI displayed
message:'The Installer encountered an error that caused the installation to
fail. Contact the software manufacturer for assistance.'.

The key part being "/Applications/NetBeans/Apache NetBeans 17.app: No such
file or directory"

Now isn't the installer supposed to make this?  I thought yes, but I
suspect things were redirected to  "/Applications/NetBeans/Apache NetBeans
17-rc3.app" during the install because of my hack to the info.plist file.
Apple is generally clever about letting users drag bundles around and still
being able to find them.  I think it did something along the lines of "I
know they want to install NB 17, and this bundle claims to be that, so we
better update that bundle instead of using the default path. Otherwise the
user will be confused."

Moral of the story - don't hack an info.plist file for beta builds. (Or if
you do, delete it before you install the final build.)

After I deleted my Frankenstein 17-rc3 application bundle, the installer
worked fine.


Scott

Re: Jackpot

[Scott Palmer]

So I've been able to get Jackpot to do some basic things by calling
directly into the cmdline tool. I'm using the Maven artifact at:

  org.apache.netbeans.modules.jackpot30:tool

So this works:

String [] args = buildCmdLineArgs();
org.netbeans.modules.jackpot30.cmdline.Main.compile(args);


Now I want to try some more fine-grained control, so I'm trying to
reproduce some of the code within the cmdline tool.
But just something simple like:

String sourceFolder = "src/main/java";
FileObject srcRoot = FileUtil.toFileObject(new File(sourceFolder));

Fails with:

java.lang.ClassNotFoundException:
org.netbeans.modules.web.common.remote.RemoteURLMapper
at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
at
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:467)
at
org.openide.util.lookup.MetaInfServicesLookup.search(MetaInfServicesLookup.java:306)
at
org.openide.util.lookup.MetaInfServicesLookup.beforeLookup(MetaInfServicesLookup.java:131)
at
org.openide.util.lookup.MetaInfServicesLookup.beforeLookupResult(MetaInfServicesLookup.java:110)
at org.openide.util.lookup.AbstractLookup.lookup(AbstractLookup.java:458)
at org.openide.util.lookup.ProxyLookup$R.initResults(ProxyLookup.java:449)
at
org.openide.util.lookup.ProxyLookup$R.addLookupListener(ProxyLookup.java:548)
at org.openide.filesystems.URLMapper.reset(URLMapper.java:92)
at org.openide.filesystems.URLMapper.(URLMapper.java:82)
at org.openide.filesystems.FileUtil.toFileObject(FileUtil.java:880)


If I call the Main.compile prior to that, it works.  But I don't see how
org.netbeans.modules.jackpot30.cmdline.Main is initializing anything to
make that work.
I suspected it is related to a few methods annotated with
org.openide.util.lookup.ServiceProvider; but that annotation is not
accessible to my code;

What's the trick to initializing things?  For now I'm hacking it by calling
Main.compile() with no args.

Other than that issue, I have been making progress with the public API.
Lots more to do though.


Thanks,

Scott

P.S.  someone should run Jackpot on the Jackpot cmdline tool - there's some
dead code in there.  It could also use some documentation, the --help
output is incomplete.

On Thu, Feb 23, 2023 at 10:42 AM Scott Palmer  wrote:

> Getting back to this...
> My netbeans-13/java/modules/ext folder contained:
> nb-javac-jdk-19-api.jar
> nb-javac-jdk-19.jar
>
> So JDK 19 versions, not 17.   I must have used a later version and not
> realized it? Or maybe I misread the instructions and thought NB 13 was a
> minimum version. I don't know, but it was clearly a mistake on my part.
> I see the build.xml in netbeans-jackpot30/cmdline/tool/ does explicitly
> references the 17 version.   I re-downloaded the binary zip for NB 13,
> which does indeed have v17 of nb-javac.  After I replaced my netbeans 13
> folder the build succeeded.
>
> I recall some talk of the nb-javac being phased out.  Is that correct?
>
> Thanks!
>
> Scott
>
>
>
>
>
>
> On Fri, Jan 27, 2023 at 1:43 AM Jan Lahoda  wrote:
>
>> Hi Scott,
>>
>> Thanks for the interest in Jackpot.
>>
>> The Maven plugin basically only calls a standalone command line tool,
>> which
>> is also uploaded on Maven central
>> (org.apache.netbeans.modules.jackpot30:tool:13.0), although that's a bit
>> harder to use without the launchers (launchers are part of the release on
>> Apache).
>>
>> Overall, the tool re-uses what's in NetBeans as much as possible, and
>> packs
>> the relevant classes into a single jar file. The main place where the
>> hints
>> (declarative or hardcoded) are ran is around this place:
>>
>> https://github.com/apache/netbeans-jackpot30/blob/13e22c19c583f2ca687f951c64aab9f3f271c0fc/cmdline/tool/src/org/netbeans/modules/jackpot30/cmdline/Main.java#L563
>>
>> Generally calls to BatchSearch, which is an internal API. It handles
>> various searches through multiple files, and then calls:
>>
>> https://github.com/apache/netbeans/blob/master/java/spi.java.hints/src/org/netbeans/modules/java/hints/spiimpl/hints/HintsInvoker.java
>>
>> which is the class that runs some list of hints over a single file.
>>
>> It should be possible to open the "cmdline" directory as a module suite in
>> NetBeans, and the "cmdline/tool" directory as a project under it.
>>
>> For building the tool, based on the NPE, it seems nb-javac was not
>> available, possibly not prepended to classpath while the tests were run.
>> It
>> is here in the NB 13 distribution:
>> java/modu

Re: Jackpot

[Scott Palmer]

Getting back to this...
My netbeans-13/java/modules/ext folder contained:
nb-javac-jdk-19-api.jar
nb-javac-jdk-19.jar

So JDK 19 versions, not 17.   I must have used a later version and not
realized it? Or maybe I misread the instructions and thought NB 13 was a
minimum version. I don't know, but it was clearly a mistake on my part.
I see the build.xml in netbeans-jackpot30/cmdline/tool/ does explicitly
references the 17 version.   I re-downloaded the binary zip for NB 13,
which does indeed have v17 of nb-javac.  After I replaced my netbeans 13
folder the build succeeded.

I recall some talk of the nb-javac being phased out.  Is that correct?

Thanks!

Scott






On Fri, Jan 27, 2023 at 1:43 AM Jan Lahoda  wrote:

> Hi Scott,
>
> Thanks for the interest in Jackpot.
>
> The Maven plugin basically only calls a standalone command line tool, which
> is also uploaded on Maven central
> (org.apache.netbeans.modules.jackpot30:tool:13.0), although that's a bit
> harder to use without the launchers (launchers are part of the release on
> Apache).
>
> Overall, the tool re-uses what's in NetBeans as much as possible, and packs
> the relevant classes into a single jar file. The main place where the hints
> (declarative or hardcoded) are ran is around this place:
>
> https://github.com/apache/netbeans-jackpot30/blob/13e22c19c583f2ca687f951c64aab9f3f271c0fc/cmdline/tool/src/org/netbeans/modules/jackpot30/cmdline/Main.java#L563
>
> Generally calls to BatchSearch, which is an internal API. It handles
> various searches through multiple files, and then calls:
>
> https://github.com/apache/netbeans/blob/master/java/spi.java.hints/src/org/netbeans/modules/java/hints/spiimpl/hints/HintsInvoker.java
>
> which is the class that runs some list of hints over a single file.
>
> It should be possible to open the "cmdline" directory as a module suite in
> NetBeans, and the "cmdline/tool" directory as a project under it.
>
> For building the tool, based on the NPE, it seems nb-javac was not
> available, possibly not prepended to classpath while the tests were run. It
> is here in the NB 13 distribution:
> java/modules/ext/nb-javac-jdk-17-api.jar
> java/modules/ext/nb-javac-jdk-17.jar
>
> And the command line that prepends it on the bootclasspath (for JDK 8), or
> excludes standard javac (for JDK 11+) is here:
>
> https://github.com/apache/netbeans-jackpot30/blob/13e22c19c583f2ca687f951c64aab9f3f271c0fc/cmdline/tool/build.xml#L115
>
> So, probably some of that didn't work well. I tried on my Linux, and it
> built, I, unfortunately, don't have a Mac to try right now. I'll keep
> thinking of it.
>
> Thanks,
>  Jan
>
>
> On Fri, Jan 27, 2023 at 5:48 AM Scott Palmer  wrote:
>
> > I haven't been able to get Jackpot to build... (If there is a better
> place
> > to ask about this, let me know)
> >
> > I followed the instructions in cmdline/README.md
> >
> > Using Ant v 1.10.12
> > Maven v 3.8.4
> > With JAVA_HOME set to JDK 8
> >
> > I ran:
> >
> > ant -DNETBEANS_PLATFORM=/Users/scott/dev/netbeans-13
> > -DJDK11=/Library/Java/JavaVirtualMachines/zulu-11.jdk/Contents/Home
> > -DJDK17=/Library/Java/JavaVirtualMachines/zulu-17.jdk/Contents/Home
> >  build-and-test
> >
> > It chugged away for a bit but then failed a bunch of tests:
> >
> > [junit] Testcase:
> >
> >
> testConfigurationFile(org.netbeans.modules.jackpot30.cmdline.CreateToolTest):
> > Caused an ERROR
> > [junit] junit.framework.AssertionFailedError: expected:<0> but
> was:<1>
> > [junit] java.io.IOException: junit.framework.AssertionFailedError:
> > expected:<0> but was:<1>
> > [junit] at
> >
> >
> org.netbeans.modules.jackpot30.cmdline.CreateToolTest.reallyRunCompiler(CreateToolTest.java:77)
> > [junit] at
> >
> >
> org.netbeans.modules.jackpot30.cmdline.MainTest.doRunCompiler(MainTest.java:1128)
> > [junit] at
> >
> >
> org.netbeans.modules.jackpot30.cmdline.MainTest.doRunCompiler(MainTest.java:1072)
> > [junit] at
> >
> >
> org.netbeans.modules.jackpot30.cmdline.MainTest.doRunCompiler(MainTest.java:1068)
> > [junit] at
> >
> >
> org.netbeans.modules.jackpot30.cmdline.MainTest.testConfigurationFile(MainTest.java:191)
> > [junit] at
> org.netbeans.junit.NbTestCase.access$200(NbTestCase.java:77)
> > [junit] at
> > org.netbeans.junit.NbTestCase$2.doSomething(NbTestCase.java:476)
> > [junit] at
> > org.netbeans.junit.NbTestCase$1Guard.run(NbTestCase.java:402)
> > [junit] at java.lang.Thread.run(Thread.java:750)
> > [junit] Caused b

Re: [External] : No communication from plugin portal verifiers (do we need to drop plugin portal?)

[Scott Palmer]

On Mon, Feb 20, 2023 at 3:28 PM Eric Bresie  wrote:

> Isn’t the whole reason for signed plugins to ensure they are provided by a
> trusted source and not tampered with by bad actors?  If no signing, does
> that add a risk of possible tainted plugins with malicious intent?
>
> Eric
>

That should be the case. Of course that also means that self-signed plugins
shouldn't be accepted either.

Jiří Kovalský: wrote:
> > It says nothing about not signed plugins but we came to the conclusion
> > that if self-signed plugins are explicitly tolerated then not-signed one
> > should not.

Which seems backwards to me.  If you allow self-signed, which is
effectively useless for verifying anything, then you should allow
not signed as it has the same security.

If certificate authorities weren't overcharging so much for a signing
certificate it wouldn't be an issue for Open Source developers that are
essentially working for free - who can afford to maintain a signing
certificate for free work?
Perhaps NetBeans/Apache should create certificates for plugin developers or
offer a signing service?

Scott


>
> On Mon, Feb 20, 2023 at 1:37 PM Matthias Bläsing
>  wrote:
>
> > Hi Jiří,
> >
> > Am Freitag, dem 17.02.2023 um 18:49 +0100 schrieb Jiří Kovalský:
> > > Anyway, I can give the context here. :) About two months ago Mani
> > > (Cc:ed here) joined the team of plugin verifiers as a new volunteer and
> > > during the introductory call with him we talked about whether plugins
> > > should be signed. As per the Plugin Verification specification [1] the
> > > installation instructions only mention:
> > >
> > > 1.8 If validation warning about self-signed certificate is displayed,
> > > accept it by clicking Continue button.
> > >
> > > [1]
> > >
> >
> https://synergy.netbeans.apache.org/#/title/verification_of_apache_netbeans_plugin/
> > >
> > > It says nothing about not signed plugins but we came to the conclusion
> > > that if self-signed plugins are explicitly tolerated then not-signed
> one
> > > should not.
> > >
> > > However, if you and Neil think that the signature check should be
> > > excluded completely and NetBeans community supports it, let's remove
> it.
> > > And even more if the whole verification process is seen as useless then
> > > let's have an official community voting and then get rid of it!
> >
> > I have mixed feeling about this, but my surprise did not come from the
> > requirement to sign the package, but from the change in policy. If the
> > plugin had not been approved multiple time before, I might have just
> > shrugged if off, this way it felt very irritating.
> >
> > Anyway, I want to focus on other things, so for now lets keep it as is.
> > Seems to be working.
> >
> > > As an immediate fix I have changed my NoGo to Go for all your 3 plugins
> > > and hereby ask Carlos/Geertjan/Mani to do the same if they agree.
> >
> > Thank you.
> >
> > Greetings
> >
> > Matthias
>
>

NB 17rc3 (and I think 16) code editor misbehaves sometimes after deleting lines

[Scott Palmer]

Has anyone else noticed that after deleting a bunch of lines the cursor
will refuse to move beyond a certain area using just the cursor keys?
E.g. I delete a chunk of lines and then hold cursor-down (or up), but the
cursor moves a few lines and then resets back to the beginning of the area
where I deleted.  It just loops over those lines.  You can click outside
that area, but editing within that area is messed up until you do.

This doesn't seem to happen every time, but it does happen enough to be
annoying.

Scott

Re: Issues with Gradle 8.0-rc-5 on NB 17rc3

[Scott Palmer]

This does seem to be a real issue, so I've filed
https://github.com/apache/netbeans/issues/5485


On Mon, Feb 13, 2023 at 12:04 PM László Kishalmi 
wrote:

> As far as I've checked the git diff between 8.0-rc-1 and 8.0-rc-5 there is
> no change in the tooling parts.
>
> On Mon, Feb 13, 2023 at 7:06 AM Scott Palmer  wrote:
>
> >
> > > On Feb 13, 2023, at 9:16 AM, Neil C Smith 
> wrote:
> > >
> > > On Sat, 11 Feb 2023 at 22:44, Scott Palmer 
> wrote:
> > >>
> > >> Trying to run multiple gradle projects from the IDE and second one
> > failed.
> > >>
> > >> A org.gradle.tooling.GradleConnectionException has occurred.
> > >>
> > >> If you are running the latest <https://netbeans.apache.org/download>
> > version
> > >> of NetBeans you can report this
> > >> <https://netbeans.apache.org/nb/report-issue>, including a copy of
> your
> > >> messages.log file as an attachment.
> > >
> > > Following that instruction would be useful! :-)
> >
> >  That would be my next step.. but I was going to do more to investigate
> > first.
> >
> > >
> > > Anything here that might cause pause for thought in progressing to
> > > release of 17?
> >
> > Sorry, I already replied to my original message, but the reply was
> blocked
> > by mailing list filters. Strange.
> >
> > The issue seems to have been related to a threading issue in my code. It
> > may have crashed the JVM (which also shouldn’t have happened, but that
> bug
> > is for someone else).  I’m going to confirm that with a smaller test case
> > and I’ll file an issue if it still seems relevant.
> >
> > At this time I don’t think it is something that should block NB 17.
> >
> > Cheers,
> >
> > Scott
> >
> > >
> > > Best wishes,
> > >
> > > Neil
> >
>

Re: NB 17rc3 Java Module caused exception in Lexer?

[Scott Palmer]

This issue doesn't seem to be Gradle related.  Did you intend to respond to
my other thread?

On Mon, Feb 13, 2023 at 11:05 AM László Kishalmi 
wrote:

> As far as I've checked the git diff between 8.0-rc-1 and 8.0-rc-5 there is
> no change in the tooling parts.
>
> On Mon, Feb 13, 2023, 07:16 Neil C Smith  wrote:
>
> > On Mon, 13 Feb 2023 at 15:11, Scott Palmer  wrote:
> > >
> > > > On Feb 13, 2023, at 9:17 AM, Neil C Smith 
> > wrote:
> > > >
> > > > On Sat, 11 Feb 2023 at 22:41, Scott Palmer 
> > wrote:
> > > >> Saw this in the messages.log for NB 17rc3
> > > >
> > > > Please can you report as a bug, with context.
> > >
> > > I’m trying to figure out the context.  I noticed it while I was looking
> > for something else.
> > > Posted here in case someone might have an idea of what could cause it.
> > > If I can reproduce it I will report the bug.
> >
> > OK, thanks!  Just going through everything that mentions 17-rc?? to
> > see where we're at with regards to release.
> >
> > Best wishes,
> >
> > Neil
> >
> > -
> > 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 17rc3 Java Module caused exception in Lexer?

[Scott Palmer]

> On Feb 13, 2023, at 9:17 AM, Neil C Smith  wrote:
> 
> On Sat, 11 Feb 2023 at 22:41, Scott Palmer  wrote:
>> Saw this in the messages.log for NB 17rc3
> 
> Please can you report as a bug, with context.

I’m trying to figure out the context.  I noticed it while I was looking for 
something else.
Posted here in case someone might have an idea of what could cause it.
If I can reproduce it I will report the bug.

Cheers,

Scott

> 
> Thanks,
> 
> Neil

-
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: Issues with Gradle 8.0-rc-5 on NB 17rc3

[Scott Palmer]

> On Feb 13, 2023, at 9:16 AM, Neil C Smith  wrote:
> 
> On Sat, 11 Feb 2023 at 22:44, Scott Palmer  wrote:
>> 
>> Trying to run multiple gradle projects from the IDE and second one failed.
>> 
>> A org.gradle.tooling.GradleConnectionException has occurred.
>> 
>> If you are running the latest <https://netbeans.apache.org/download> version
>> of NetBeans you can report this
>> <https://netbeans.apache.org/nb/report-issue>, including a copy of your
>> messages.log file as an attachment.
> 
> Following that instruction would be useful! :-)

 That would be my next step.. but I was going to do more to investigate first.

> 
> Anything here that might cause pause for thought in progressing to
> release of 17?

Sorry, I already replied to my original message, but the reply was blocked by 
mailing list filters. Strange.

The issue seems to have been related to a threading issue in my code. It may 
have crashed the JVM (which also shouldn’t have happened, but that bug is for 
someone else).  I’m going to confirm that with a smaller test case and I’ll 
file an issue if it still seems relevant.

At this time I don’t think it is something that should block NB 17.

Cheers,

Scott

> 
> Best wishes,
> 
> Neil

Re: Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))

[Scott Palmer]

While I appreciate Jaroslav's point about libraries being compatible with a
wide variety of Java versions, we do have to balance that with keeping up
with recent developments and the extra effort it entails to avoid using
modern features that are otherwise available.
I personally don't see an issue in dropping Java 8 as a minimum platform
for building or running NetBeans. If you want to run on Java 8, you are
already accustomed to living in the past - you can deal with an older
version of NB or the NB platform that supports Java 8.  I say that however,
having no stake in a NB platform app. It isn't going to affect me. My vote
shouldn't count for much.

But NB or the NB platform isn't the only library an application will use,
and many others are already starting to raise the bar as far as the minimum
supported JDK/JRE.  You can only go back as far as all of your dependencies
will allow.  If there is demand for it, a Java 8 compatible maintenance
branch can be made. One reason for running on JDK 8 mentioned running on
Android.  Are there a significant number of NB platform apps that run on
Android now?  Do they already build with the latest NB platform, or are
they already using an older version anyway - i.e. being on the lastest NB
platform may not be a big deal for them.

An informed decision needs to be based on these details.  Holding back for
JDK 8 compatibility helps no one if there isn't actually any real demand to
do so.

Just my 2c,

Scott


On Sun, Feb 12, 2023 at 5:22 PM Neil C Smith  wrote:

> On Sun, 12 Feb 2023, 19:11 Matthias Bläsing,
>  wrote:
>
> > Hi,
> >
> > Am Freitag, dem 10.02.2023 um 10:12 + schrieb Neil C Smith:
> > > On Thu, 9 Feb 2023 at 19:02, Matthias Bläsing <
> mblaes...@doppel-helix.eu.invalid>
> > wrote:
> > > > - commit to make NetBeans runnable on JDK LTS -1
> > > > - build with JDK LTS -1
> > > > - be able to be build with the current JDK
> > >
> > > +1 as long as that includes the platform.
> > >
> > > That is what I suggested in the other thread (I don't see why we need
> > > multiple threads incidentally!)
> > >
> > > An LTS-1 strategy seems closest to how NetBeans used to function -
> > > major-1, in a time when it also had more development resources?
> > >
> > > Let's also be clear, though, that adopting an LTS-1 strategy means
> > > dropping JDK 11 support either in our first release after JDK 21, or
> > > the first after JDK 22 - so latest May 2024.
> >
> > why would we do that? I said _runnable_ and _buildable_. As long as the
> > current JDK support the target release I did not exclude that.
> >
>
> In which case I don't understand what you mean by committing to make
> NetBeans buildable and runnable on LTS-1? That to me means dropping the
> commitment to JDK 11 when it becomes LTS-2.
>
>
>
> > > > - keep as many modules as feasible compatible with release 8
> > >
> > > -1 : A number of things have come up recently about preparing for JDK
> > > 21+ that would involve increasing the bytecode level and APIs in some
> > > core parts of the NetBeans runtime container.
> >
> > Could you elaborate what that is? Not using Thread#stop and dropping
> > finalizers is it not. That can be done (with some pain) with support
> > for 8. So what is the problem?
> >
>
> Yes, those and I think some others. My paragraph after the one you quoted
> was acknowledging we can do this for 8 with some pain (headache). The
> question is whether it is worth it?
>
> Best wishes,
>
> Neil
>

Re: Gradle Distribution Settings

[Scott Palmer]

I’m an odd ball with more than just my Gradle setup 藍 

Basically I just want to use the latest version unless I need to pin it down 
for compatibility.  That lets me see when I’m using something that has been 
deprecated etc.

Regarding the Gradle User Home setting… I think these days the people that have 
multiple drives and need to have Gradle store artifacts outside of their home 
directory likely know various ways to make that happen (e.g. symlink or env 
var).  As I stated, we don’t have a similar override for Maven (which has other 
ways to deal with it as well), so we don’t likely need this.  In any case 
running from the command line, I doubt users would want to always type the 
--gradle-user-home option (or remember to if they’ve changed the setting in 
NB), they probably set the GRADLE_USER_HOME environment variable.  That should 
solve the issue for NetBeans as well.

You could always keep the ability behind a more generic list of additional 
options to add to Gradle commands.  Like the way you can add arguments to build 
actions from the project settings.

Cheers,

Scott

> On Feb 12, 2023, at 12:29 AM, Laszlo Kishalmi  
> wrote:
> 
> Dear Scott,
> 
> You are an odd ball with your setup. I'm sure you are doing that for a 
> reason, so that should be appreciated. Thank you for your feedback! It seems 
> the custom distribution is here to stay.
> 
> Setting the Gradle Home is for those (poor) people, who have limited space on 
> their home directory (wrong PC setup, educational setups, etc.), so they 
> could pack their stuff somewhere else.
> 
> I'm going to think about your ideas as well! Once again, Thank you for 
> speaking up!
> 
>> On 2/11/23 15:32, Scott Palmer wrote:
>> Gradle wrapper should always be the default if it is initialized.  So I 
>> would reverse the logic for the "Prefer to use Gradle Wrapper" checkbox and 
>> change the main part of the Gradle settings dialog to, e.g:
>> 
>> [checkbox] Override Project Gradle Version
>> 
>> Default Gradle Distribution:
>> [radio] Use Standard Gradle Version: [combobox]
>> [radio] Custom: [path field][browse button]
>> 
>> If the wrapper isn't configured for a project, the default version is 
>> implied.
>> 
>> "Gradle User Home" should be an advanced setting that isn't normally 
>> visible, or just remove it.  There is no such setting to override the Maven 
>> Home, why do we have it for Gradle?
>> "Start Gradle Daemon on IDE Start" isn't needed.  If you are opening Gradle 
>> projects as the IDE restores the last open projects, starting the daemons 
>> needed will happen anyway.
>> "Install Gradle Runtime Silently" isn't needed.  It's implied that this will 
>> happen if "Default Gradle Distribution" is not set to "Custom"
>> 
>> When a new project is made, it uses the Gradle init logic which will 
>> automatically configure the Gradle Wrapper with the default Gradle version.  
>>  So most NB-created projects will have a "project" setting for what Gradle 
>> to use.  The use of the wrapper is a best practice, so I think this makes 
>> sense.
>> 
>> The Project Properties should show the current version configured for the 
>> Gradle Wrapper and allow it to be changed.
>> If the wrapper is not configured for a project, instead it should show a 
>> button to "Initialize Gradle Wrapper with Gradle version: [combobox]"  The 
>> combobox includes all standard versions and is pre-selected with the word 
>> "Default" and the version number of "custom" in parenthesis. e.g. "Default 
>> (7.6)" or "Default (custom)"
>> 
>> Regards,
>> 
>> Scott
>> 
>> On Sat, Feb 11, 2023 at 5:59 PM Scott Palmer  wrote:
>> 
>>I don't use the wrapper until a project is final or I have to
>>share it.
>>I am almost always on the bleeding edge as far as Gradle
>>versions.  I keep all of my projects on the most recent Gradle
>>version when I work on them, often on the latest release candidate
>>(unless I encounter problems - which I want to be aware of so I
>>can report them or fix my scripts).  The wrapper just adds
>>overhead for my day to day usage. I don't need a zillion versions
>>of Gradle cached on my system.  If the project is to be shared,
>>then I add the wrapper because then it makes sense.
>> 
>>My NB settings are such that I use a version of Gradle at a fixed
>>location via Custom Gradle Distribution, which is just a symlink
>>to the latest version of Gradle that I have downloaded.  That
>&g

Re: Gradle Distribution Settings

[Scott Palmer]

Gradle wrapper should always be the default if it is initialized.  So I
would reverse the logic for the "Prefer to use Gradle Wrapper" checkbox and
change the main part of the Gradle settings dialog to, e.g:

[checkbox] Override Project Gradle Version

Default Gradle Distribution:
[radio] Use Standard Gradle Version: [combobox]
[radio] Custom: [path field][browse button]

If the wrapper isn't configured for a project, the default version is
implied.

"Gradle User Home" should be an advanced setting that isn't normally
visible, or just remove it.  There is no such setting to override the Maven
Home, why do we have it for Gradle?
"Start Gradle Daemon on IDE Start" isn't needed.  If you are opening Gradle
projects as the IDE restores the last open projects, starting the daemons
needed will happen anyway.
"Install Gradle Runtime Silently" isn't needed.  It's implied that this
will happen if "Default Gradle Distribution" is not set to "Custom"

When a new project is made, it uses the Gradle init logic which will
automatically configure the Gradle Wrapper with the default Gradle version.
  So most NB-created projects will have a "project" setting for what Gradle
to use.  The use of the wrapper is a best practice, so I think this makes
sense.

The Project Properties should show the current version configured for the
Gradle Wrapper and allow it to be changed.
If the wrapper is not configured for a project, instead it should show a
button to "Initialize Gradle Wrapper with Gradle version: [combobox]"  The
combobox includes all standard versions and is pre-selected with the word
"Default" and the version number of "custom" in parenthesis. e.g. "Default
(7.6)" or "Default (custom)"

Regards,

Scott


On Sat, Feb 11, 2023 at 5:59 PM Scott Palmer  wrote:

> I don't use the wrapper until a project is final or I have to share it.
> I am almost always on the bleeding edge as far as Gradle versions.  I keep
> all of my projects on the most recent Gradle version when I work on
> them, often on the latest release candidate (unless I encounter problems -
> which I want to be aware of so I can report them or fix my scripts).  The
> wrapper just adds overhead for my day to day usage. I don't need a zillion
> versions of Gradle cached on my system.  If the project is to be shared,
> then I add the wrapper because then it makes sense.
>
> My NB settings are such that I use a version of Gradle at a fixed location
> via Custom Gradle Distribution, which is just a symlink to the
> latest version of Gradle that I have downloaded.  That symlink is also on
> my path.  So I'm using the latest Gradle in NB and from the command line,
> unless I invoke the wrapper instead.
>
> So I don't want the Custom Gradle Distribution option to go away.
>
> The Gradle User Home option is useless to me.  I don't understand why I
> would ever want to change that.  That's just asking for trouble as then my
> command line builds would be doing something different from my NB builds
> and I don't want that.
> [image: image.png]
> Scott
>
> On Sat, Feb 11, 2023 at 2:39 AM Laszlo Kishalmi 
> wrote:
>
>> Dear all,
>>
>> I'd like to collect some feedback on the Gradle Distribution Settings
>> (Tools > Options > Java > Gradle > Execution Panel > Distribution Section)
>>
>> Over the years, Gradle evolved and some usage patterns has changed.
>>
>> 8 years ago, Gradle Daemon was in incubation phase. It could took a few
>> (5-10) seconds to start a daemon especially with HDDs.
>> People usually installed some latest Gradle and used that globally,
>> wrapper was not yet popular.
>>
>> I think the following settings are obsolete:
>>- Start Gradle Daemon on IDE Start: Most people are using wrappers,
>> so a daemon with the IDE defined distribution, just wasting resources.
>>- Install Gradle Runtime Silently (Project trust is fine for that)
>>
>> The following options are questionable:
>>Custom Gradle Distribution. (I think I've used only once around 2.3
>> when I built my own Gradle distribution due to a bug in Gradle)
>>
>> The Gradle Distribution Selector Combo Box is over engineered. I would
>> replace that and the
>> "Prefer to Use Gradle Wrapper that Comes with the Project" check box in
>> a simple combo with elements:
>> Wrapper
>> 8.0
>> 7.6
>> 
>> 3.0
>>
>> I would drop the selection below at least 3.0 (Gradle 2.x are ancient,
>> and there are a few versions which are not working well with NetBeans)
>>
>> So at the end I would keep the Gradle Home and the combined distribution
>> selector. Probably move that to root project level as well.
>>
>> What do you think?
>>
>>
>> -
>> 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: Gradle Distribution Settings

[Scott Palmer]

I don't use the wrapper until a project is final or I have to share it.
I am almost always on the bleeding edge as far as Gradle versions.  I keep
all of my projects on the most recent Gradle version when I work on
them, often on the latest release candidate (unless I encounter problems -
which I want to be aware of so I can report them or fix my scripts).  The
wrapper just adds overhead for my day to day usage. I don't need a zillion
versions of Gradle cached on my system.  If the project is to be shared,
then I add the wrapper because then it makes sense.

My NB settings are such that I use a version of Gradle at a fixed location
via Custom Gradle Distribution, which is just a symlink to the
latest version of Gradle that I have downloaded.  That symlink is also on
my path.  So I'm using the latest Gradle in NB and from the command line,
unless I invoke the wrapper instead.

So I don't want the Custom Gradle Distribution option to go away.

The Gradle User Home option is useless to me.  I don't understand why I
would ever want to change that.  That's just asking for trouble as then my
command line builds would be doing something different from my NB builds
and I don't want that.
[image: image.png]
Scott

On Sat, Feb 11, 2023 at 2:39 AM Laszlo Kishalmi 
wrote:

> Dear all,
>
> I'd like to collect some feedback on the Gradle Distribution Settings
> (Tools > Options > Java > Gradle > Execution Panel > Distribution Section)
>
> Over the years, Gradle evolved and some usage patterns has changed.
>
> 8 years ago, Gradle Daemon was in incubation phase. It could took a few
> (5-10) seconds to start a daemon especially with HDDs.
> People usually installed some latest Gradle and used that globally,
> wrapper was not yet popular.
>
> I think the following settings are obsolete:
>- Start Gradle Daemon on IDE Start: Most people are using wrappers,
> so a daemon with the IDE defined distribution, just wasting resources.
>- Install Gradle Runtime Silently (Project trust is fine for that)
>
> The following options are questionable:
>Custom Gradle Distribution. (I think I've used only once around 2.3
> when I built my own Gradle distribution due to a bug in Gradle)
>
> The Gradle Distribution Selector Combo Box is over engineered. I would
> replace that and the
> "Prefer to Use Gradle Wrapper that Comes with the Project" check box in
> a simple combo with elements:
> Wrapper
> 8.0
> 7.6
> 
> 3.0
>
> I would drop the selection below at least 3.0 (Gradle 2.x are ancient,
> and there are a few versions which are not working well with NetBeans)
>
> So at the end I would keep the Gradle Home and the combined distribution
> selector. Probably move that to root project level as well.
>
> What do you think?
>
>
> -
> 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
>
>
>
>

Issues with Gradle 8.0-rc-5 on NB 17rc3

[Scott Palmer]

Trying to run multiple gradle projects from the IDE and second one failed.

A org.gradle.tooling.GradleConnectionException has occurred.

If you are running the latest  version
of NetBeans you can report this
, including a copy of your
messages.log file as an attachment.

The messages.log file is located in this folder.

This exception was in messages.log:

SEVERE [global]
org.gradle.launcher.daemon.client.DaemonConnectionException: Timeout
waiting to connect to the Gradle daemon.
Daemon uid: a9f8350f-10e3-4d84-8ab4-19c2edcfb978 with diagnostics:
Daemon pid: 13657
  log file: /Users/scott/.gradle/daemon/8.0-rc-5/daemon-13657.out.log
- Last  20 lines from daemon log file - daemon-13657.out.log -
2023-02-11T17:26:16.409-0500 [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon
addresses registry.
2023-02-11T17:26:16.409-0500 [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon
addresses registry.
2023-02-11T17:26:26.400-0500 [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire
shared lock on daemon addresses registry.
2023-02-11T17:26:26.400-0500 [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon
addresses registry.
2023-02-11T17:26:26.400-0500 [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon
addresses registry.
2023-02-11T17:26:26.401-0500 [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire
shared lock on daemon addresses registry.
2023-02-11T17:26:26.401-0500 [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon
addresses registry.
2023-02-11T17:26:26.401-0500 [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon
addresses registry.
2023-02-11T17:26:26.401-0500 [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire
shared lock on daemon addresses registry.
2023-02-11T17:26:26.402-0500 [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon
addresses registry.
2023-02-11T17:26:26.402-0500 [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon
addresses registry.
2023-02-11T17:26:36.403-0500 [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire
shared lock on daemon addresses registry.
2023-02-11T17:26:36.403-0500 [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon
addresses registry.
2023-02-11T17:26:36.404-0500 [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon
addresses registry.
2023-02-11T17:26:36.404-0500 [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire
shared lock on daemon addresses registry.
2023-02-11T17:26:36.404-0500 [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon
addresses registry.
2023-02-11T17:26:36.404-0500 [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon
addresses registry.
2023-02-11T17:26:36.404-0500 [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire
shared lock on daemon addresses registry.
2023-02-11T17:26:36.405-0500 [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon
addresses registry.
2023-02-11T17:26:36.405-0500 [DEBUG]
[org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon
addresses registry.
- End of the daemon log -

at
org.gradle.launcher.daemon.client.DefaultDaemonConnector.doStartDaemon(DefaultDaemonConnector.java:242)
at
org.gradle.launcher.daemon.client.DefaultDaemonConnector.startDaemon(DefaultDaemonConnector.java:216)
at
org.gradle.launcher.daemon.client.DaemonClient.execute(DaemonClient.java:164)
at
org.gradle.launcher.daemon.client.DaemonClient.execute(DaemonClient.java:99)
at
org.gradle.tooling.internal.provider.DaemonBuildActionExecuter.execute(DaemonBuildActionExecuter.java:44)
at
org.gradle.tooling.internal.provider.DaemonBuildActionExecuter.execute(DaemonBuildActionExecuter.java:30)
at
org.gradle.tooling.internal.provider.LoggingBridgingBuildActionExecuter.execute(LoggingBridgingBuildActionExecuter.java:60)
at
org.gradle.tooling.internal.provider.LoggingBridgingBuildActionExecuter.execute(LoggingBridgingBuildActionExecuter.java:37)
at
org.gradle.tooling.internal.provider.ProviderConnection.run(ProviderConnection.java:224)
at
org.gradle.tooling.internal.provider.ProviderConnection.run(ProviderConnection.java:150)
at
org.gradle.tooling.internal.provider.DefaultConnection.getModel(DefaultConnection.java:149)
at
org.gradle.tooling.internal.consumer.connection.CancellableModelBuilderBackedModelProducer.produceModel(CancellableModelBuilderBackedModelProducer.java:54)
at

NB 17rc3 Java Module caused exception in Lexer?

[Scott Palmer]

Saw this in the messages.log for NB 17rc3

INFO [org.netbeans.ui.indexing]: Indexing finished, indexing took 0 ms.
SEVERE [org.openide.util.Exceptions]
java.util.ConcurrentModificationException: Caller uses obsolete token
sequence which is no longer valid. Underlying token hierarchy has been
modified by insertion or removal or a custom language embedding was
created.TS.modCount=1460, tokenList.modCount()=1462, rootModCount=1462
Please report a bug against a module that calls lexer's code e.g. java, php
etc. but not the lexer module itself.
at org.netbeans.api.lexer.TokenSequence.checkValid(TokenSequence.java:784)
at org.netbeans.api.lexer.TokenSequence.moveIndex(TokenSequence.java:568)
at
org.netbeans.modules.java.editor.base.semantic.TokenList.resetToIndex(TokenList.java:372)
at
org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.visitMethodInvocation(SemanticHighlighterBase.java:781)
at
org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.visitMethodInvocation(SemanticHighlighterBase.java:316)
at
com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1815)
at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:92)
at
org.netbeans.api.java.source.support.CancellableTreePathScanner.scan(CancellableTreePathScanner.java:69)
at
org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.scan(SemanticHighlighterBase.java:1121)
at
org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.scan(SemanticHighlighterBase.java:316)
at
com.sun.source.util.TreeScanner.visitExpressionStatement(TreeScanner.java:502)
at
org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.visitExpressionStatement(SemanticHighlighterBase.java:861)
at
org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.visitExpressionStatement(SemanticHighlighterBase.java:316)
at
com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1594)
at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:92)
at
org.netbeans.api.java.source.support.CancellableTreePathScanner.scan(CancellableTreePathScanner.java:69)
at
org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.scan(SemanticHighlighterBase.java:1121)
at
org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.scan(SemanticHighlighterBase.java:316)
at com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:96)
at com.sun.source.util.TreeScanner.scan(TreeScanner.java:111)
at
org.netbeans.api.java.source.support.CancellableTreePathScanner.scan(CancellableTreePathScanner.java:78)
at com.sun.source.util.TreeScanner.visitBlock(TreeScanner.java:272)
at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1094)
at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:92)
at
org.netbeans.api.java.source.support.CancellableTreePathScanner.scan(CancellableTreePathScanner.java:69)
at
org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.scan(SemanticHighlighterBase.java:1121)
at
org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.visitMethod(SemanticHighlighterBase.java:934)
at
org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.visitMethod(SemanticHighlighterBase.java:316)
at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:944)
at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:92)
at
org.netbeans.api.java.source.support.CancellableTreePathScanner.scan(CancellableTreePathScanner.java:69)
at
org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.scan(SemanticHighlighterBase.java:1121)
at
org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.scan(SemanticHighlighterBase.java:316)
at com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:96)
at com.sun.source.util.TreeScanner.scan(TreeScanner.java:111)
at
org.netbeans.api.java.source.support.CancellableTreePathScanner.scan(CancellableTreePathScanner.java:78)
at
org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.visitClass(SemanticHighlighterBase.java:1049)
at
org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.visitClass(SemanticHighlighterBase.java:316)
at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:851)
at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:92)
at
org.netbeans.api.java.source.support.CancellableTreePathScanner.scan(CancellableTreePathScanner.java:69)
at
org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.scan(SemanticHighlighterBase.java:1121)
at
org.netbeans.modules.java.editor.base.semantic.SemanticHighlighterBase$DetectorVisitor.scan(SemanticHighlighterBase.java:316)
at 

Re: NB 17-rc2 Javadoc Popups Render Incorrectly

[Scott Palmer]

Filed JavaDoc popup renders incorrectly · Issue #5403 · apache/netbeans
(github.com) 

I'm not sure if I'll have time to get to a PR on this one before someone
else, but if nobody gets to it for a while I may take a crack at it.

Cheers,

Scott


On Wed, Feb 1, 2023 at 7:41 AM Neil C Smith  wrote:

> On Wed, 1 Feb 2023 at 02:15, Michael Bien  wrote:
> >
> > seems to be happening with NB 16 too so its not a regression at least.
> >
> > Would be good to file an issue so that we don't forget about this.
>
> Yes, an issue would be good, if not a PR! :-)
>
> I assume this is down to a missing Kind at
>
> https://github.com/apache/netbeans/blob/master/java/java.sourceui/src/org/netbeans/api/java/source/ui/ElementJavadoc.java#L1230
>
> The recent PR for @summary is probably worth a look
> https://github.com/apache/netbeans/pull/5180
>
> I don't know if there's any way to offer a sensible default in that
> switch?  At least rendering the text inside unknown tags might be
> good, although I'm not sure how feasible that is in practice?
>
> Best wishes,
>
> Neil
>

NB 17-rc2 Javadoc Popups Render Incorrectly

[Scott Palmer]

I just noticed that the popup JavaDocs render incorrectly. For
example, ClassLoader.getSystemClassLoader() has is a sentence in the
Javadoc referring to a system property, it shows as:

If the system property "" is defined when...

Notice the empty string.  If you click the button to view in a browser you
will see that this should read:

If the system property "java.system.class.loader" is defined when...

Note that the string between the quotes is in fixed-width code style.
A similar omission occurs later on in the docs:

For debugging purposes, ignored entries can be printed to the console if
the system property is set to true.

The actual text is:

For debugging purposes, ignored entries can be printed to the console
if the jdk.net.URLClassPath.showIgnoredClassPathEntries system property is
set to true.

again, the text rendered as fixed-width code is missing in the NB popup.


Regards,

Scott

Re: NB 17-rc2 Rename Refactoring silently failed

[Scott Palmer]

Yes.. well maybe...
For that project the source level is set to 17, but the Java Runtime for
Gradle execution is set to JDK 19.  The build.gradle file uses the
toolchain mechanism to specify JDK 17.  The JDK 19 reference is likely left
over from some experiments. They are all valid JDK folders, but I thought
maybe the mix of 17 & 19 was causing NB some confusion, so I changed it to
JDK 17 (default) and even restarted NB, but the problem remains.
NetBeans is running with netbeans_jdkhome set to 17 in the netbeans.conf
file.

Scott

On Mon, Jan 30, 2023 at 8:37 AM Neil C Smith  wrote:

> On Mon, 30 Jan 2023 at 00:16, Scott Palmer  wrote:
> > More failures to rename...
> > ...
> > Even though the source level of ... is set to: 17, java.util.zip.CRC32C
> cannot be found on the system module
> > path:
>
> That seems suspicious.  Are you sure the jdkhome for the IDE and any
> per-project platform are correctly configured?
>
> Neil
>
> -
> 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 17-rc2 Rename Refactoring silently failed

[Scott Palmer]

s.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:287)
at
org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)
ALL [null]: An error occurred during parsing of
'/Users/scott/dev/Personal/Grade/src/main/java/com/analogideas/grade/inspector/impl/AntlrInspectionHelper.java'.
Please report a bug against java/source and attach dump file
'/Users/scott/Library/Application
Support/NetBeans/17-rc2/var/log/AntlrInspectionHelper.dump'.
SEVERE [null]: Last record repeated again.


On Sun, Jan 29, 2023 at 5:45 PM Scott Palmer  wrote:

> Checking the logs
>
> I noticed a typo in a warning message, "evaulate" instead of "evaluate":
> INFO [org.netbeans.modules.gradle.execute.GradleDistributionProviderImpl]:
> Cannot evaulate Gradle Wrapper
>
> I also see an assertion to do with VanillaCompileWorker that is repeated a
> few times... I'm guessing something isn't happy with the use of the "yield"
> keyword in the relatively new switch expressions.
>
> SEVERE [org.openide.util.Exceptions]
> java.lang.AssertionError
> at com.sun.tools.javac.util.Assert.error(Assert.java:155)
> at com.sun.tools.javac.util.Assert.checkNonNull(Assert.java:62)
> at com.sun.tools.javac.util.ListBuffer.append(ListBuffer.java:127)
> at com.sun.tools.javac.comp.Attr$1.visitYield(Attr.java:1637)
> at com.sun.tools.javac.tree.JCTree$JCYield.accept(JCTree.java:1660)
> at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
> at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:57)
> at
> com.sun.tools.javac.comp.Attr.lambda$visitSwitchExpression$7(Attr.java:1644)
> at com.sun.tools.javac.comp.Attr.handleSwitch(Attr.java:1827)
> at
> com.sun.tools.javac.comp.Attr.visitSwitchExpression(Attr.java:1629)
> at
> com.sun.tools.javac.tree.JCTree$JCSwitchExpression.accept(JCTree.java:1382)
> at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:687)
> at com.sun.tools.javac.comp.Attr.visitReturn(Attr.java:2452)
> at
> com.sun.tools.javac.tree.JCTree$JCReturn.accept(JCTree.java:1711)
> at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:687)
> at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:761)
> at com.sun.tools.javac.comp.Attr.attribStats(Attr.java:780)
> at com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:1464)
> at
> org.netbeans.lib.nbjavac.services.NBAttr.visitBlock(NBAttr.java:78)
> at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1082)
> at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:687)
> at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:761)
> at com.sun.tools.javac.comp.Attr.visitMethodDef(Attr.java:1254)
> at
> org.netbeans.lib.nbjavac.services.NBAttr.visitMethodDef(NBAttr.java:72)
> at
> com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:912)
> at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:687)
> at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:761)
> at com.sun.tools.javac.comp.Attr.attribClassBody(Attr.java:5604)
> at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:5495)
> at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:5319)
> at com.sun.tools.javac.comp.Attr.attrib(Attr.java:5258)
> at
> com.sun.tools.javac.main.JavaCompiler.attribute(JavaCompiler.java:1317)
> at
> com.sun.tools.javac.api.JavacTaskImpl$1.process(JavacTaskImpl.java:409)
> at
> com.sun.tools.javac.api.JavacTaskImpl$Filter.run(JavacTaskImpl.java:519)
> at
> com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:412)
> [catch] at
> org.netbeans.modules.java.source.indexing.VanillaCompileWorker.compile(VanillaCompileWorker.java:284)
> at
> org.netbeans.modules.java.source.indexing.JavaCustomIndexer.index(JavaCustomIndexer.java:360)
> at
> org.netbeans.modules.parsing.spi.indexing.Indexable$MyAccessor$2.run(Indexable.java:138)
> at
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.runIndexer(RepositoryUpdater.java:274)
> at
> org.netbeans.modules.parsing.spi.indexing.Indexable$MyAccessor.index(Indexable.java:136)
> at
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.doIndex(RepositoryUpdater.java:2749)
> at
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.lambda$index$0(RepositoryUpdater.java:2626)
> at
> org.netbeans.modules.parsing.impl.indexing.errors.TaskCache.refreshTransaction(TaskCache.java:540)
> at
> org.netbeans.modules.pars

Re: NB 17-rc2 Rename Refactoring silently failed

[Scott Palmer]

es(RepositoryUpdater.java:5443)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$RootsWork.getDone(RepositoryUpdater.java:5075)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$InitialRootsWork.getDone(RepositoryUpdater.java:5842)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.doTheWork(RepositoryUpdater.java:3452)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task._run(RepositoryUpdater.java:6197)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task.access$3400(RepositoryUpdater.java:5855)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task$2.lambda$call$0(RepositoryUpdater.java:6116)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:288)
at
org.netbeans.modules.parsing.impl.RunWhenScanFinishedSupport.performScan(RunWhenScanFinishedSupport.java:83)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task$2.call(RepositoryUpdater.java:6116)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task$2.call(RepositoryUpdater.java:6112)
at
org.netbeans.modules.masterfs.filebasedfs.utils.FileChangedManager.priorityIO(FileChangedManager.java:153)
at
org.netbeans.modules.masterfs.providers.ProvidedExtensions.priorityIO(ProvidedExtensions.java:335)
at
org.netbeans.modules.parsing.nb.DataObjectEnvFactory.runPriorityIO(DataObjectEnvFactory.java:118)
at
org.netbeans.modules.parsing.impl.Utilities.runPriorityIO(Utilities.java:67)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task.run(RepositoryUpdater.java:6112)
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
at
java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418)
at
org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:287)
at
org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)
WARNING [org.netbeans.modules.java.source.indexing.JavaIndex]:
VanillaCompileWorker caused an exception



After attempting the refactoring (which still doesn't work after a restart
and wiping the cache), this is all that was added to the log  (WidgetUtils
iconButtonForAction is the method I'm trying to rename):

INFO [org.netbeans.modules.gradle.loaders.GradleProjectLoaderImpl]: Load
aiming EVALUATED for Unloaded Gradle Project:
GradleFiles[projectDir=/Users/scott/dev/Personal/IncludedBuildSample/Library,
rootDir=/Users/scott/dev/Personal/IncludedBuildSample/Library]
INFO [org.netbeans.api.java.source.ElementHandle]: Cannot resolve:
ElementHandle[kind=METHOD; sigs=com.analogideas.grade.ui.WidgetUtils
iconButtonForAction
(Lcom/analogideas/grade/ui/Action;Ljavafx/scene/Node;)Ljavafx/scene/control/Button;
]
INFO [org.netbeans.api.java.source.TreePathHandle]: Cannot resolve:
TreePathHandle[delegate:TreeDelegate[kind:METHOD,
enclosingElement:ElementHandle[kind=METHOD;
sigs=com.analogideas.grade.ui.WidgetUtils iconButtonForAction
(Lcom/analogideas/grade/ui/Action;Ljavafx/scene/Node;)Ljavafx/scene/control/Button;
],
file:/Users/scott/dev/Personal/Grade/src/main/java/com/analogideas/grade/ui/WidgetUtils.java@4af9037d
:6de8552e]]
INFO [org.netbeans.api.java.source.ElementHandle]: Cannot resolve:
ElementHandle[kind=METHOD; sigs=com.analogideas.grade.ui.WidgetUtils
iconButtonForAction
(Lcom/analogideas/grade/ui/Action;Ljavafx/scene/Node;)Ljavafx/scene/control/Button;
]
INFO [null]: Last record repeated again.
INFO [org.netbeans.api.java.source.TreePathHandle]: Cannot resolve:
TreePathHandle[delegate:TreeDelegate[kind:METHOD,
enclosingElement:ElementHandle[kind=METHOD;
sigs=com.analogideas.grade.ui.WidgetUtils iconButtonForAction
(Lcom/analogideas/grade/ui/Action;Ljavafx/scene/Node;)Ljavafx/scene/control/Button;
],
file:/Users/scott/dev/Personal/Grade/src/main/java/com/analogideas/grade/ui/WidgetUtils.java@4af9037d
:6de8552e]]
INFO [org.netbeans.modules.refactoring.spi.impl.ParametersPanel]:
org.netbeans.modules.refactoring.api.AbstractRefactoring$ProgressL@36591bc1
called start multiple times


Regards,

Scott


On Sun, Jan 29, 2023 at 1:49 PM Laszlo Kishalmi 
wrote:

> Can you check the message log for an earlier exception, maybe regarding
> java parser?
>
> The mentioned exception is logging some null handle at:
>
> https://github.com/apache/netbeans/blob/d018622771aa7910274cb7260a87f6793061f431/java/refactoring.java/src/org/netbeans/modules/refactoring/java/ui/RenameRefactoringUI.java#L424
>
> On 1/29/23 09:50, Scott Palmer wrote:
> > I had some trouble trying to do a simple rename of a public static
> utility
> > method.  When I tried renaming it from where the method was defined it
> > resulted in the following message.  (It's a lie. In f

NB 17-rc2 Rename Refactoring silently failed

[Scott Palmer]

I had some trouble trying to do a simple rename of a public static utility
method.  When I tried renaming it from where the method was defined it
resulted in the following message.  (It's a lie. In fact "find usages" on
this method has no problem.)

"The original element being refactored is not available. It was deleted or
significantly changed. Usages cannot be collected."

When I tried to rename from a call site there was no warning or error, but
then it did nothing.
The following exception was in messages.log:

java.lang.NullPointerException: selected
 at
org.netbeans.modules.refactoring.java.ui.RenameRefactoringUI$2.create(RenameRefactoringUI.java:424)
 at
org.netbeans.modules.refactoring.java.ui.ContextAnalyzer$1.createRefactoringUI(ContextAnalyzer.java:94)
 at
org.netbeans.modules.refactoring.java.ui.ContextAnalyzer$TextComponentTask.run(ContextAnalyzer.java:355)
 at
org.netbeans.modules.refactoring.java.ui.ContextAnalyzer$TextComponentTask.run(ContextAnalyzer.java:280)
 at
org.netbeans.api.java.source.JavaSource$MultiTask.run(JavaSource.java:504)
 at
org.netbeans.modules.parsing.impl.TaskProcessor.callUserTask(TaskProcessor.java:586)
 at
org.netbeans.modules.parsing.api.ParserManager$UserTaskAction.run(ParserManager.java:132)
 at
org.netbeans.modules.parsing.api.ParserManager$UserTaskAction.run(ParserManager.java:116)
 at
org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:181)
 at
org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:178)
 at
org.netbeans.modules.masterfs.filebasedfs.utils.FileChangedManager.priorityIO(FileChangedManager.java:153)
 at
org.netbeans.modules.masterfs.providers.ProvidedExtensions.priorityIO(ProvidedExtensions.java:335)
 at
org.netbeans.modules.parsing.nb.DataObjectEnvFactory.runPriorityIO(DataObjectEnvFactory.java:118)
 at
org.netbeans.modules.parsing.impl.Utilities.runPriorityIO(Utilities.java:67)
 at
org.netbeans.modules.parsing.impl.TaskProcessor.runUserTask(TaskProcessor.java:178)
 at
org.netbeans.modules.parsing.api.ParserManager.parse(ParserManager.java:83)
 at
org.netbeans.api.java.source.JavaSource.runUserActionTaskImpl(JavaSource.java:454)
 at
org.netbeans.api.java.source.JavaSource.runUserActionTask(JavaSource.java:425)
 at
org.netbeans.modules.refactoring.java.ui.ContextAnalyzer$TextComponentTask.run(ContextAnalyzer.java:362)
 at
org.netbeans.modules.refactoring.java.ui.UIUtilities.lambda$runWhenScanFinished$0(UIUtilities.java:1194)
 at
org.netbeans.api.java.source.ui.ScanDialog.runWhenScanFinished(ScanDialog.java:133)
 at
org.netbeans.modules.refactoring.java.ui.UIUtilities.runWhenScanFinished(UIUtilities.java:1189)
 at
org.netbeans.modules.refactoring.java.ui.RefactoringActionsProvider.doFullRename(RefactoringActionsProvider.java:128)
 at
org.netbeans.modules.refactoring.java.ui.RefactoringActionsProvider.doRename(RefactoringActionsProvider.java:75)
 at
org.netbeans.modules.refactoring.api.impl.ActionsImplementationFactory.doRename(ActionsImplementationFactory.java:66)
 at
org.netbeans.modules.refactoring.spi.impl.RenameAction.performAction(RenameAction.java:52)
 at
org.netbeans.modules.refactoring.spi.impl.RefactoringGlobalAction$ContextAction.actionPerformed(RefactoringGlobalAction.java:172)
 at
org.netbeans.modules.java.editor.rename.InstantRenamePerformer.doFullRename(InstantRenamePerformer.java:260)
 at
org.netbeans.modules.java.editor.rename.InstantRenamePerformer.invokeInstantRename(InstantRenamePerformer.java:243)
 at
org.netbeans.modules.java.editor.rename.InstantRenameAction.actionPerformed(InstantRenameAction.java:37)
 at org.netbeans.editor.BaseAction.actionPerformed(BaseAction.java:324)

Re: Jackpot

[Scott Palmer]

I haven't been able to get Jackpot to build... (If there is a better place
to ask about this, let me know)

I followed the instructions in cmdline/README.md

Using Ant v 1.10.12
Maven v 3.8.4
With JAVA_HOME set to JDK 8

I ran:

ant -DNETBEANS_PLATFORM=/Users/scott/dev/netbeans-13
-DJDK11=/Library/Java/JavaVirtualMachines/zulu-11.jdk/Contents/Home
-DJDK17=/Library/Java/JavaVirtualMachines/zulu-17.jdk/Contents/Home
 build-and-test

It chugged away for a bit but then failed a bunch of tests:

[junit] Testcase:
testConfigurationFile(org.netbeans.modules.jackpot30.cmdline.CreateToolTest):
Caused an ERROR
[junit] junit.framework.AssertionFailedError: expected:<0> but was:<1>
[junit] java.io.IOException: junit.framework.AssertionFailedError:
expected:<0> but was:<1>
[junit] at
org.netbeans.modules.jackpot30.cmdline.CreateToolTest.reallyRunCompiler(CreateToolTest.java:77)
[junit] at
org.netbeans.modules.jackpot30.cmdline.MainTest.doRunCompiler(MainTest.java:1128)
[junit] at
org.netbeans.modules.jackpot30.cmdline.MainTest.doRunCompiler(MainTest.java:1072)
[junit] at
org.netbeans.modules.jackpot30.cmdline.MainTest.doRunCompiler(MainTest.java:1068)
[junit] at
org.netbeans.modules.jackpot30.cmdline.MainTest.testConfigurationFile(MainTest.java:191)
[junit] at org.netbeans.junit.NbTestCase.access$200(NbTestCase.java:77)
[junit] at
org.netbeans.junit.NbTestCase$2.doSomething(NbTestCase.java:476)
[junit] at org.netbeans.junit.NbTestCase$1Guard.run(NbTestCase.java:402)
[junit] at java.lang.Thread.run(Thread.java:750)
[junit] Caused by: junit.framework.AssertionFailedError: expected:<0>
but was:<1>
[junit] at
org.netbeans.modules.jackpot30.cmdline.CreateToolTest.reallyRunCompiler(CreateToolTest.java:72)
[junit]
[junit]
[junit] Testcase:
testWarningsAreErrors(org.netbeans.modules.jackpot30.cmdline.CreateToolTest):
FAILED
[junit] expected:<[${workdir}/src/test/Test.java:4: warning:
[Usage_of_Collection_Map_size_equals_0] c.size() == 0 can be replaced with
c.isEmpty()
[junit] boolean b1 = c.size() == 0;
[junit]  ^
[junit] ${workdir}/src/test/Test.java:5: warning:
[Usage_of_Collection_Map_size_equals_0] c.size() == 0 can be replaced with
c.isEmpty()
[junit] boolean b2 = c.size() == 0;
[junit] ^
[junit] ]> but was:<[]>

Basically a few like above, and then a lot more that looked like this:

[junit] Testcase:
testParameterFile(org.netbeans.modules.jackpot30.cmdline.MainTest): Caused
an ERROR
[junit] java.lang.NullPointerException
[junit] java.lang.IllegalStateException: java.lang.NullPointerException
[junit] at
org.netbeans.modules.jackpot30.cmdline.Main.compile(Main.java:357)
[junit] at
org.netbeans.modules.jackpot30.cmdline.MainTest.reallyRunCompiler(MainTest.java:1155)
[junit] at
org.netbeans.modules.jackpot30.cmdline.MainTest.doRunCompiler(MainTest.java:1128)
[junit] at
org.netbeans.modules.jackpot30.cmdline.MainTest.doRunCompiler(MainTest.java:1072)
[junit] at
org.netbeans.modules.jackpot30.cmdline.MainTest.doRunCompiler(MainTest.java:1068)
[junit] at
org.netbeans.modules.jackpot30.cmdline.MainTest.testParameterFile(MainTest.java:879)
[junit] at org.netbeans.junit.NbTestCase.access$200(NbTestCase.java:77)
[junit] at
org.netbeans.junit.NbTestCase$2.doSomething(NbTestCase.java:476)
[junit] at org.netbeans.junit.NbTestCase$1Guard.run(NbTestCase.java:402)
[junit] at java.lang.Thread.run(Thread.java:750)
[junit] Caused by: java.lang.NullPointerException
[junit] at
org.netbeans.modules.java.hints.spiimpl.batch.BatchSearch.findOccurrencesLocal(BatchSearch.java:92)
[junit] at
org.netbeans.modules.java.hints.spiimpl.batch.BatchSearch.findOccurrences(BatchSearch.java:85)
[junit] at
org.netbeans.modules.jackpot30.cmdline.Main.handleGroup(Main.java:564)
[junit] at
org.netbeans.modules.jackpot30.cmdline.Main.compile(Main.java:338)


Any hints are appreciated.

Regards,

Scott


On Thu, Jan 26, 2023 at 1:49 PM Ernie Rael  wrote:

> On 23/01/26 10:25 AM, Scott Palmer wrote:
> > Well, yeah of course.. but is there a documented public API?
> > The maven plugin doesn't actually do refactoring, right?  It just
> > identifies hints?
>
> At: https://netbeans.apache.org/jackpot/
>
> > To apply the changes produced by the declarative hints, run
> > jackpot30:apply:
> > $ mvn -q jackpot30:apply && git diff
>
> Haven't tried it, but sure looks like it does the refactoring.
>
> -ernie
>
> > I was just wondering if there are notes somewhere that go a bit deeper
> than
> > showing how to use it from the command line or NetBeans.
> >
> > I did find a README in the cmdline folder.  So at least that's a start
> for
> > getting something to build.
> >
> > Thanks,
> 

Re: NB 17-rc2 Gradle "included builds" are missing from class path

[Scott Palmer]

Interestingly, while making this test case the issue only appeared after I
made the included library modular, and even then I had to restart NB for
the issue to show up.
So I can't be certain if this wasn't also an issue with 17-rc1, as I may
not have restarted NB 17-rc1 after making my actual library modular.
Perhaps I only noticed it in NB 17-rc2 because of course NB was restarted.

Zip File attached with an application project and a library project that it
uses includeBuild to reference.  If the list drops it due to no attachment
rules, I've BCC'd you László.

Open just the "MainApp" project in NB and it will show errors, but the
build will work fine.

Regards,

Scott

On Thu, Jan 26, 2023 at 4:22 PM László Kishalmi 
wrote:

> Is this a regression between NB17-rc1 and NB17-rc2 ?
>
> If I may ask, could you provide a sample project?
>
> On Thu, Jan 26, 2023 at 12:29 PM Scott Palmer  wrote:
>
> > No, all those details are in the libs.versions.toml file.
> >
> > [versions]
> > fxsvg = "1.0.0"
> >
> > [libraries]
> > fxsvg = { module = "com.analogideas.fxsvg:fxsvg", version.ref = "fxsvg" }
> >
> > On Thu, Jan 26, 2023 at 3:19 PM László Kishalmi <
> laszlo.kisha...@gmail.com
> > >
> > wrote:
> >
> > > Shoudn't you use the :[:] reference there?
> > >
> > > On Thu, Jan 26, 2023 at 10:46 AM Scott Palmer 
> > wrote:
> > >
> > > > I have a project that uses another library I am working on.  The
> > library
> > > is
> > > > not deployed to any artifact repository (i.e. not even the maven
> local
> > > > cache), but it does define a group and name.  I included it in the
> > > project
> > > > that uses it as an "included build"
> > > >
> > > > In NB 17-rc1 this project was recognized and the imports that
> referred
> > to
> > > > it didn't show any problems.
> > > > In NB 17-rc2 the import line is marked with an error that the package
> > > does
> > > > not exist.
> > > > The project still builds and runs fine, but the IDE thinks there are
> > > errors
> > > > because of this.
> > > >
> > > > settings.gradle contains:
> > > >
> > > > includeBuild '../fxsvg'
> > > >
> > > > and the build.gradle file refers to it as an implementation
> dependency
> > > via
> > > > a reference defined in gradle/libs.versions.toml
> > > >
> > > > implementation libs.fxsvg
> > > >
> > > >
> > > > 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

Re: NB 17-rc2 Gradle "included builds" are missing from class path

[Scott Palmer]

No, all those details are in the libs.versions.toml file.

[versions]
fxsvg = "1.0.0"

[libraries]
fxsvg = { module = "com.analogideas.fxsvg:fxsvg", version.ref = "fxsvg" }

On Thu, Jan 26, 2023 at 3:19 PM László Kishalmi 
wrote:

> Shoudn't you use the :[:] reference there?
>
> On Thu, Jan 26, 2023 at 10:46 AM Scott Palmer  wrote:
>
> > I have a project that uses another library I am working on.  The library
> is
> > not deployed to any artifact repository (i.e. not even the maven local
> > cache), but it does define a group and name.  I included it in the
> project
> > that uses it as an "included build"
> >
> > In NB 17-rc1 this project was recognized and the imports that referred to
> > it didn't show any problems.
> > In NB 17-rc2 the import line is marked with an error that the package
> does
> > not exist.
> > The project still builds and runs fine, but the IDE thinks there are
> errors
> > because of this.
> >
> > settings.gradle contains:
> >
> > includeBuild '../fxsvg'
> >
> > and the build.gradle file refers to it as an implementation dependency
> via
> > a reference defined in gradle/libs.versions.toml
> >
> > implementation libs.fxsvg
> >
> >
> > Regards,
> >
> > Scott
> >
>

NB 17-rc2 Gradle "included builds" are missing from class path

[Scott Palmer]

I have a project that uses another library I am working on.  The library is
not deployed to any artifact repository (i.e. not even the maven local
cache), but it does define a group and name.  I included it in the project
that uses it as an "included build"

In NB 17-rc1 this project was recognized and the imports that referred to
it didn't show any problems.
In NB 17-rc2 the import line is marked with an error that the package does
not exist.
The project still builds and runs fine, but the IDE thinks there are errors
because of this.

settings.gradle contains:

includeBuild '../fxsvg'

and the build.gradle file refers to it as an implementation dependency via
a reference defined in gradle/libs.versions.toml

implementation libs.fxsvg


Regards,

Scott

Re: Jackpot

[Scott Palmer]

Well, yeah of course.. but is there a documented public API?
The maven plugin doesn't actually do refactoring, right?  It just
identifies hints?
I was just wondering if there are notes somewhere that go a bit deeper than
showing how to use it from the command line or NetBeans.

I did find a README in the cmdline folder.  So at least that's a start for
getting something to build.

Thanks,

Scott

On Thu, Jan 26, 2023 at 11:22 AM Michael Bien  wrote:

> you check how the maven plugin is implemented and adopt it for gradle?
>
> -mbien
>
> On 26.01.23 17:13, Scott Palmer wrote:
>
> I don't use Maven if I can help it.
>
> But you misunderstand, I want to call Jackpot from my code to get it to
> perform some refactoring from control of my program. Getting a list of
> possible hints may happen later.
> Or perhaps a more general use... What would I do if I wanted to write a
> Gradle plugin to do the same as the Maven plugin? Assuming I know the
> Gradle side, how do I call the Jackpot methods?
>
> Regards,
>
> Scott
>
>
> On Thu, Jan 26, 2023 at 10:50 AM Michael Bien  wrote:
>
>> On 26.01.23 16:01, Scott Palmer wrote:
>> > I wanted to experiment with Jackpot for a project I'm working on.  How
>> > dependent on the NetBeans Platform is the Jackpot code at
>> > https://github.com/apache/netbeans-jackpot30 ?
>> > Is there such a thing as a jackpot library jar that does not depend on
>> > NetBeans classes?
>> > If I wanted to make a standalone tool to do certain transformations on a
>> > Java code base where would I start?
>> >
>> > Thanks for any help you can provide,
>> >
>> > Scott
>> >
>> you should be able to use it from maven in your build:
>>
>>  
>> org.apache.netbeans.modules.jackpot30
>> jackpot30-maven-plugin
>>  13.0
>>  
>> jackpot-settings.xml
>> true
>>  
>>  
>>  
>>  jackpot
>>  compile
>>  
>>  analyze
>>  
>>  
>>  
>>  
>>
>>
>> I use it mostly from within NetBeans itself for refactoring or
>> inspection tasks with the help of the ".hint" files.
>>
>> I sometimes upload the inspections which I think are reusable or more
>> generic here:
>>
>> https://github.com/mbien/jackpot-inspections
>>
>> readme explains how to use hint files.
>>
>> -mbien
>>
>>
>

Re: Jackpot

[Scott Palmer]

I don't use Maven if I can help it.

But you misunderstand, I want to call Jackpot from my code to get it to
perform some refactoring from control of my program. Getting a list of
possible hints may happen later.
Or perhaps a more general use... What would I do if I wanted to write a
Gradle plugin to do the same as the Maven plugin? Assuming I know the
Gradle side, how do I call the Jackpot methods?

Regards,

Scott


On Thu, Jan 26, 2023 at 10:50 AM Michael Bien  wrote:

> On 26.01.23 16:01, Scott Palmer wrote:
> > I wanted to experiment with Jackpot for a project I'm working on.  How
> > dependent on the NetBeans Platform is the Jackpot code at
> > https://github.com/apache/netbeans-jackpot30 ?
> > Is there such a thing as a jackpot library jar that does not depend on
> > NetBeans classes?
> > If I wanted to make a standalone tool to do certain transformations on a
> > Java code base where would I start?
> >
> > Thanks for any help you can provide,
> >
> > Scott
> >
> you should be able to use it from maven in your build:
>
>  
> org.apache.netbeans.modules.jackpot30
> jackpot30-maven-plugin
>  13.0
>  
> jackpot-settings.xml
> true
>  
>  
>  
>  jackpot
>  compile
>  
>  analyze
>  
>  
>  
>  
>
>
> I use it mostly from within NetBeans itself for refactoring or
> inspection tasks with the help of the ".hint" files.
>
> I sometimes upload the inspections which I think are reusable or more
> generic here:
>
> https://github.com/mbien/jackpot-inspections
>
> readme explains how to use hint files.
>
> -mbien
>
>

Jackpot

[Scott Palmer]

I wanted to experiment with Jackpot for a project I'm working on.  How
dependent on the NetBeans Platform is the Jackpot code at
https://github.com/apache/netbeans-jackpot30 ?
Is there such a thing as a jackpot library jar that does not depend on
NetBeans classes?
If I wanted to make a standalone tool to do certain transformations on a
Java code base where would I start?

Thanks for any help you can provide,

Scott

Re: NB 17-rc1 Scrollbar in Debug Output is broken

[Scott Palmer]

I should add that I noticed that when I scroll through the output by
swiping on the mouse instead of grabbing the scrollbar, that the thumb
position doesn't update.


On Sun, Jan 22, 2023 at 6:12 PM Scott Palmer  wrote:

> I'm not sure how new this is, I may have seen it with NB 16.   The
> vertical scroll bar in the output window is stuck at a fixed size.  If the
> output area is made taller the scroll bar starts at the top and ends short
> of the bottom.  If the output area is made shorter, the end will be pushed
> off the bottom, sometimes hiding the "thumb" completely.  This is happening
> only in the main output pane when I debug the application.  Other panes of
> the output tab, like the "Debugger Console", and Mercurial output don't
> show this problem.
>
> This is on macOS with FlatLaF Dark, JDK 17.0.6.
>
> Scott
>
>

NB 17-rc1 Scrollbar in Debug Output is broken

[Scott Palmer]

I'm not sure how new this is, I may have seen it with NB 16.   The vertical
scroll bar in the output window is stuck at a fixed size.  If the output
area is made taller the scroll bar starts at the top and ends short of the
bottom.  If the output area is made shorter, the end will be pushed off the
bottom, sometimes hiding the "thumb" completely.  This is happening only in
the main output pane when I debug the application.  Other panes of the
output tab, like the "Debugger Console", and Mercurial output don't show
this problem.

This is on macOS with FlatLaF Dark, JDK 17.0.6.

Scott

Re: Gradle 8.0-rc-2 Issues

[Scott Palmer]

example that fails with runSingle: https://github.com/swpalmer/RunSingle


On Fri, Jan 20, 2023 at 5:59 PM Scott Palmer  wrote:

> Sorry, I think the Gradle 7.5.1 I saw in some error messages must have
> been from a project that used it via the wrapper.  I have too many projects
> loaded!
>
> I will try to put together a simple multi-project example that shows the
> issue I have.
>
> Cheers,
>
> Scott
>
> On Fri, Jan 20, 2023 at 2:12 PM László Kishalmi 
> wrote:
>
>> Well, first of all NB17-rc1 bundles Gradle 8.0-rc-1. Unfortunately I have
>> no NB17-rc1 at hand, but have the latest dev build from master (which is
>> almost identical to the rc1 this time).
>>
>> So with that build, I see runSingle action works correctly when used on a
>> simple NetBeans created Java Application or Library project. The injected
>> task is rather simple. It just creates a simple JavaExec task with the
>> main
>> classpath and the java class to be executed.
>>
>> If someone needs something more sophisticated, it is always possible to
>> create a runSingle task in the project. in that case NetBeans would use
>> that task.
>>
>> Of course we can improve as well, though it would be good to have a sample
>> project on github or attached as a zip to have a clear base of
>> understanding.
>>
>> The Gradle plugin in NB needs a better support for Java Toolchain. I have
>> plans for that, unfortunately it did not fit in the NB17 release window.
>>
>> On Thu, Jan 19, 2023 at 7:26 PM Scott Palmer  wrote:
>>
>> > So it seems runSingle isn't working properly for a build that has
>> > subprojects.  I have a main project that has two subprojects and the
>> > runSingle task was injected into a subproject as well when I tried to
>> run a
>> > file in the main project.  So the main project succeeded, and then the
>> > subproject was confused.
>> > Here is the output of running the 'Test' class in the main project:
>> >
>> > > Task :runSingle
>> > done
>> >
>> > > Task :Model:runSingle FAILED
>> > Error: Could not find or load main class example.Test
>> > Caused by: java.lang.ClassNotFoundException: example.Test
>> >
>> > The 'Model' project failed.  It doesn't depend on the main project, the
>> > dependency is the other way around, so of course the class was not
>> found.
>> >
>> > I also just discovered that the injected runSingle task can get confused
>> > about the toolchain. The toolchain is set to 19 in the gradle script,
>> but
>> > with Source/Binary format set to the 'default' in the NB project
>> settings.
>> > If that doesn't match, things can go wrong. The result is that if NB is
>> > running on JDK 17, the classes are compiled for JDK 19 and NB ends up
>> > trying to run JDK 19 classes with JDK 17 runtime.  The
>> > Source/Binary settings in the project dialog shouldn't be mismatched of
>> > course. I wonder if NB can detect the use of the Gradle toolchain
>> support
>> > and make it read-only and set to the value used for the toolchain?
>> >
>> > It looks like NB 17 is embedding and using Gradle 7.5.x for some things
>> as
>> > well.  Will that be updated to 7.6 before release?
>> >
>> > Scott
>> >
>> > On Thu, Jan 19, 2023 at 7:54 PM Scott Palmer 
>> wrote:
>> >
>> > > So runSingle still fails with NB 17-rc1 and Gradle 8.0-rc-2
>> > >
>> > > > Task :Model:runSingle FAILED
>> > > Error: Could not find or load main class example.Test
>> > > Caused by: java.lang.ClassNotFoundException: example.Test
>> > >
>> > > Scott
>> > >
>> > > On Thu, Jan 19, 2023 at 11:47 AM Scott Palmer 
>> > wrote:
>> > >
>> > >> Yes, I noticed shortly after I sent my msg.  So far NB 17-rc1 is
>> doing
>> > >> much better!
>> > >>
>> > >> On Thu, Jan 19, 2023 at 9:21 AM Neil C Smith 
>> > >> wrote:
>> > >>
>> > >>> On Thu, 19 Jan 2023 at 14:16, Scott Palmer 
>> wrote:
>> > >>> > That’s NB16 with the Gradle update.  I can try to build 17 to see
>> how
>> > >>> it goes there.
>> > >>>
>> > >>> 17-rc1 literally just announced.  Please try that and report issues
>> > >>> that might need fixing before release.
>> > >>>
>> > >>> Neil
>> > >>>
>> > >>>
>> -
>> > >>> 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: Gradle 8.0-rc-2 Issues

[Scott Palmer]

Sorry, I think the Gradle 7.5.1 I saw in some error messages must have been
from a project that used it via the wrapper.  I have too many projects
loaded!

I will try to put together a simple multi-project example that shows the
issue I have.

Cheers,

Scott

On Fri, Jan 20, 2023 at 2:12 PM László Kishalmi 
wrote:

> Well, first of all NB17-rc1 bundles Gradle 8.0-rc-1. Unfortunately I have
> no NB17-rc1 at hand, but have the latest dev build from master (which is
> almost identical to the rc1 this time).
>
> So with that build, I see runSingle action works correctly when used on a
> simple NetBeans created Java Application or Library project. The injected
> task is rather simple. It just creates a simple JavaExec task with the main
> classpath and the java class to be executed.
>
> If someone needs something more sophisticated, it is always possible to
> create a runSingle task in the project. in that case NetBeans would use
> that task.
>
> Of course we can improve as well, though it would be good to have a sample
> project on github or attached as a zip to have a clear base of
> understanding.
>
> The Gradle plugin in NB needs a better support for Java Toolchain. I have
> plans for that, unfortunately it did not fit in the NB17 release window.
>
> On Thu, Jan 19, 2023 at 7:26 PM Scott Palmer  wrote:
>
> > So it seems runSingle isn't working properly for a build that has
> > subprojects.  I have a main project that has two subprojects and the
> > runSingle task was injected into a subproject as well when I tried to
> run a
> > file in the main project.  So the main project succeeded, and then the
> > subproject was confused.
> > Here is the output of running the 'Test' class in the main project:
> >
> > > Task :runSingle
> > done
> >
> > > Task :Model:runSingle FAILED
> > Error: Could not find or load main class example.Test
> > Caused by: java.lang.ClassNotFoundException: example.Test
> >
> > The 'Model' project failed.  It doesn't depend on the main project, the
> > dependency is the other way around, so of course the class was not found.
> >
> > I also just discovered that the injected runSingle task can get confused
> > about the toolchain. The toolchain is set to 19 in the gradle script, but
> > with Source/Binary format set to the 'default' in the NB project
> settings.
> > If that doesn't match, things can go wrong. The result is that if NB is
> > running on JDK 17, the classes are compiled for JDK 19 and NB ends up
> > trying to run JDK 19 classes with JDK 17 runtime.  The
> > Source/Binary settings in the project dialog shouldn't be mismatched of
> > course. I wonder if NB can detect the use of the Gradle toolchain support
> > and make it read-only and set to the value used for the toolchain?
> >
> > It looks like NB 17 is embedding and using Gradle 7.5.x for some things
> as
> > well.  Will that be updated to 7.6 before release?
> >
> > Scott
> >
> > On Thu, Jan 19, 2023 at 7:54 PM Scott Palmer  wrote:
> >
> > > So runSingle still fails with NB 17-rc1 and Gradle 8.0-rc-2
> > >
> > > > Task :Model:runSingle FAILED
> > > Error: Could not find or load main class example.Test
> > > Caused by: java.lang.ClassNotFoundException: example.Test
> > >
> > > Scott
> > >
> > > On Thu, Jan 19, 2023 at 11:47 AM Scott Palmer 
> > wrote:
> > >
> > >> Yes, I noticed shortly after I sent my msg.  So far NB 17-rc1 is doing
> > >> much better!
> > >>
> > >> On Thu, Jan 19, 2023 at 9:21 AM Neil C Smith 
> > >> wrote:
> > >>
> > >>> On Thu, 19 Jan 2023 at 14:16, Scott Palmer 
> wrote:
> > >>> > That’s NB16 with the Gradle update.  I can try to build 17 to see
> how
> > >>> it goes there.
> > >>>
> > >>> 17-rc1 literally just announced.  Please try that and report issues
> > >>> that might need fixing before release.
> > >>>
> > >>> Neil
> > >>>
> > >>> -
> > >>> 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: Gradle 8.0-rc-2 Issues

[Scott Palmer]

So it seems runSingle isn't working properly for a build that has
subprojects.  I have a main project that has two subprojects and the
runSingle task was injected into a subproject as well when I tried to run a
file in the main project.  So the main project succeeded, and then the
subproject was confused.
Here is the output of running the 'Test' class in the main project:

> Task :runSingle
done

> Task :Model:runSingle FAILED
Error: Could not find or load main class example.Test
Caused by: java.lang.ClassNotFoundException: example.Test

The 'Model' project failed.  It doesn't depend on the main project, the
dependency is the other way around, so of course the class was not found.

I also just discovered that the injected runSingle task can get confused
about the toolchain. The toolchain is set to 19 in the gradle script, but
with Source/Binary format set to the 'default' in the NB project settings.
If that doesn't match, things can go wrong. The result is that if NB is
running on JDK 17, the classes are compiled for JDK 19 and NB ends up
trying to run JDK 19 classes with JDK 17 runtime.  The
Source/Binary settings in the project dialog shouldn't be mismatched of
course. I wonder if NB can detect the use of the Gradle toolchain support
and make it read-only and set to the value used for the toolchain?

It looks like NB 17 is embedding and using Gradle 7.5.x for some things as
well.  Will that be updated to 7.6 before release?

Scott

On Thu, Jan 19, 2023 at 7:54 PM Scott Palmer  wrote:

> So runSingle still fails with NB 17-rc1 and Gradle 8.0-rc-2
>
> > Task :Model:runSingle FAILED
> Error: Could not find or load main class example.Test
> Caused by: java.lang.ClassNotFoundException: example.Test
>
> Scott
>
> On Thu, Jan 19, 2023 at 11:47 AM Scott Palmer  wrote:
>
>> Yes, I noticed shortly after I sent my msg.  So far NB 17-rc1 is doing
>> much better!
>>
>> On Thu, Jan 19, 2023 at 9:21 AM Neil C Smith 
>> wrote:
>>
>>> On Thu, 19 Jan 2023 at 14:16, Scott Palmer  wrote:
>>> > That’s NB16 with the Gradle update.  I can try to build 17 to see how
>>> it goes there.
>>>
>>> 17-rc1 literally just announced.  Please try that and report issues
>>> that might need fixing before release.
>>>
>>> Neil
>>>
>>> -
>>> 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: Gradle 8.0-rc-2 Issues

[Scott Palmer]

So runSingle still fails with NB 17-rc1 and Gradle 8.0-rc-2

> Task :Model:runSingle FAILED
Error: Could not find or load main class example.Test
Caused by: java.lang.ClassNotFoundException: example.Test

Scott

On Thu, Jan 19, 2023 at 11:47 AM Scott Palmer  wrote:

> Yes, I noticed shortly after I sent my msg.  So far NB 17-rc1 is doing
> much better!
>
> On Thu, Jan 19, 2023 at 9:21 AM Neil C Smith 
> wrote:
>
>> On Thu, 19 Jan 2023 at 14:16, Scott Palmer  wrote:
>> > That’s NB16 with the Gradle update.  I can try to build 17 to see how
>> it goes there.
>>
>> 17-rc1 literally just announced.  Please try that and report issues
>> that might need fixing before release.
>>
>> Neil
>>
>> -
>> 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: Gradle 8.0-rc-2 Issues

[Scott Palmer]

Yes, I noticed shortly after I sent my msg.  So far NB 17-rc1 is doing much
better!

On Thu, Jan 19, 2023 at 9:21 AM Neil C Smith  wrote:

> On Thu, 19 Jan 2023 at 14:16, Scott Palmer  wrote:
> > That’s NB16 with the Gradle update.  I can try to build 17 to see how it
> goes there.
>
> 17-rc1 literally just announced.  Please try that and report issues
> that might need fixing before release.
>
> Neil
>
> -
> 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: Gradle 8.0-rc-2 Issues

[Scott Palmer]

That’s NB16 with the Gradle update.  I can try to build 17 to see how it goes 
there.

Scott

> On Jan 18, 2023, at 11:34 PM, Laszlo Kishalmi  
> wrote:
> 
> Is that on NB16 or the upcoming 17?
> 
> NB16 is not compatible with Gradle 8.0. We had to do a bunch of fixes for 
> that.
> 
>> On 1/18/23 20:26, Scott Palmer wrote:
>> Gradle projects using Gradle 8.0-rc-1 and 2 show a problem with 
>> org.gradle.api.tasks.bundling.Jar.getClassifier()
>> All NetBeans says is that there is a warning. No other details. Nothing 
>> relevant in messages.log
>> image.png
>> 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

Gradle 8.0-rc-2 Issues

[Scott Palmer]

Gradle projects using Gradle 8.0-rc-1 and 2 show a problem with
org.gradle.api.tasks.bundling.Jar.getClassifier()
All NetBeans says is that there is a warning. No other details. Nothing
relevant in messages.log
[image: image.png]
Regards,

Scott

Prepare for more Gradle tweaks

[Scott Palmer]

I just noticed that the injected 'runSingle' task seems to provoke this
warning"

> Task :app:runSingle
Hello World!

Deprecated Gradle features were used in this build, making it incompatible
with Gradle 8.0.

That's running the Java file from NetBeans with Gradle 7.5 via the
Gradle Wrapper.  Doing a 'clean build' gives no such warning.
Gradle 8.0-rc-1 is already available, so we better get on this stuff...

I changed the run.single parameters to add '--warning-mode all --stacktrace'
to get more specific information:

The JavaExec.main property has been deprecated. This is scheduled to be
removed in Gradle 8.0. Please use the mainClass property instead. See
https://docs.gradle.org/7.5/dsl/org.gradle.api.tasks.JavaExec.html#org.gradle.api.tasks.JavaExec:main
for more details.
at org.gradle.api.tasks.JavaExec.setMain(JavaExec.java:427)
at org.gradle.api.tasks.JavaExec_Decorated.setMain(Unknown Source)
at
org.netbeans.modules.gradle.tooling.NetBeansRunSinglePlugin.lambda$addTask$2(NetBeansRunSinglePlugin.java:85)

I filed issue #5267 
and created pull-request #5268


Cheers,

Scott

Re: Copy Paste still an issue

[Scott Palmer]

I’ve still had to paste into another application sometimes and then copy again 
to get NB 16 to recognize what I had copied from somewhere else so it would 
paste that instead of what it had internally. 

Scott

> On Dec 5, 2022, at 9:33 PM, Eirik Bakke  wrote:
> 
> Yes, there was a patch here in NetBeans 15 which I think improved the 
> situation a lot. Now you can usually just Ctrl+C again, which so far has 
> always resolved the problem for me. (Instead of restarting the IDE.)
> 
> The patch was https://github.com/apache/netbeans/pull/4774 , which was a 
> follow-up on https://github.com/apache/netbeans/pull/4572 . I kept a diary of 
> cut/paste problems and their resolution for several weeks.
> 
> -- Eirik
> 
> 
> Great! There was a patch in NetBeans 15 that made the copy/paste bug much 
> less of a problem.
> 
> -Original Message-
> From: Patrik Karlström  
> Sent: Monday, December 5, 2022 9:18 AM
> To: dev@netbeans.apache.org
> Subject: Re: Copy Paste still an issue
> 
> There are a couple of threads on this by now and I'm not sure if the 
> following "semi-solution" has been posted.
> 
> A couple of weeks ago the clipboard went bust on me in NB 15.
> I tried a couple of things and I got it working again without restarting NB.
> 
> Today it happened again but this time in NB 16, this gave me a chance to 
> reduce and verify my steps.
> The only thing I needed to do to make the clipboard working again was
> 
> Hit CTRL-X in NB without any selection being made (cut the whole line).
> Perhaps CTRL-C works too.
> 
> Patrik
> 
> 
> Den lör 3 sep. 2022 kl 11:07 skrev Neil C Smith :
> 
>>> On Fri, 2 Sept 2022 at 18:45, Kenneth Fogel 
>>> 
>>> wrote:
>>> To reproduce try this:
>>> 
>>> Open NB and a project in NB. Open NotePad++ or Word.
>>> Copy just one line of a file from NB to NotePad++ or Word. It should
>> work. Try a few other lines but just a single line at a time.
>>> Now select and copy 20 or so lines from the NB file. **You will not 
>>> be
>> able to paste it**.
>> 
>> It would be easier if it was that easily reproducible!  Are you saying 
>> that you see this every time?  Other people have reported it happening 
>> after some time, some not seeing it.
>> 
>> Can you try setting some thing in netbeans.conf startup properties?
>> 
>> -J-Dorg.netbeans.NbClipboard.level=FINEST
>> 
>> Then check messages.  Anything odd?
>> 
>> Then try adding to that -
>> 
>> -J-Dnetbeans.slow.system.clipboard.hack=false
>> 
>> and
>> 
>> -J-DTopSecurityManager.disable=true
>> 
>> separately - not at the same time.
>> 
>> Do either/both affect the result?
>> 
>> Thanks,
>> 
>> Neil
>> 
>> -
>> 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
> 
> 
> 

-
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

'Move Inner to Outer...' refactoring of a nested record fails

[Scott Palmer]

I had a class that has within it a simple record:

 // class and interface names changed for my amusement
public abstract class ScottsAwesomeClass implements AmazingThings { 

static record Location(int line, int column) {}

// … a lot more stuff ...
}


I placed the cursor on the word “Location” and right-clicked to select the 
refactoring “Move Inner to Outer Level…”
Leaving the defaults in the dialog that appeared and hit “Refactor”.

The result was a new source file for a *class* named Location in the same 
package:

class Location {
}

Oh and the new Location.java file did NOT contain the configured license header.
And it is very much not at all the equivalent of:

record Location(int line, int column) {}

It also changed the references to the record, in a different source file for a 
class extending ScottsAwesomeClass, to fully qualified references to the new 
Location class, despite all classes/records being in the same package and the 
original reference using the ‘var’ keyword.

In other words, it went badly. ;-)

I’m guessing the refactoring has simply not been updated to handle records?


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

Re: [VOTE] Release Apache NetBeans 16 macOS installer

[Scott Palmer]

+1 (non-binding)

Installed on macOS 13.1 without issues.  
(Though it did run with JDK 19, as expected,  so I have to tweak that so I can 
open my Gradle projects.)

> On Nov 28, 2022, at 6:06 PM, John Mc  wrote:
> 
> Vote for Apache NetBeans 16 macOS installer.
> 
> Primary voting artefact :
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-installers/16/Apache-NetBeans-16-bin-macosx.dmg
> 
> SHA512 checksum :
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-installers/16/Apache-NetBeans-16-bin-macosx.dmg.sha512
> 
> a4294a59335e10975ef42d5b4a8f16a26f98019c22c89ebff81d645a8cdc1a307ce904a06600ecfd5f121307d03c40a755dd1aaeb65b9e851ac0534f9cdb6970
> 
> KEYS file :
> https://dist.apache.org/repos/dist/release/netbeans/KEYS
> 
> PGP signature file :
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-installers/16/Apache-NetBeans-16-bin-macosx.dmg.asc
> 
> Built locally using the artefacts found in the Jenkins job:
> https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/netbeans/job/release160/11/
> 
> This vote is going to be open at least 72 hours, vote with +1, 0, and
> -1 as usual. Please mark your vote with (binding) if you're an Apache
> NetBeans PMC member.
> 
> This vote is dependent on the main Apache NetBeans 16 release vote passing.
> 
> Regards
> 
> John


-
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: Bad sample code in Formatting preferences for Java

[Scott Palmer]

> On Nov 28, 2022, at 2:46 PM, Scott Palmer  wrote:
> 
> 
>> On Nov 28, 2022, at 1:58 PM, Michael Bien  wrote:
>> 
>> On 28.11.22 20:00, Neil C Smith wrote:
>>> On Mon, 28 Nov 2022 at 18:55, Scott Palmer >> <mailto:swpal...@gmail.com>> wrote:
>>>> In preferences/settings under Editor, Formatting, language Java, category 
>>>> Spaces:
>>>> 
>>>> The sample code used has a misplaced closing brace.  Instead of closing 
>>>> the ‘meth’ method it is after the following “add” method, ending the 
>>>> example with a double “} }” on the same line.
>>> So it does.  Can you open a GH issue?
>> 
>> or PR :)
> 
> 
> Issue 5023 filed.  
> PR to come, I hope... we’ll see how the fight with git goes. (I use Mercurial 
> because I’m not a masochist :-). )

Well it seems UI have to win the fight with Ant first :-)

Using Ant 1.10.12, JDK 17.0.5 on macOS 13.1, I tried:

ant -Dcluster.config=basic

and got:

BUILD FAILED
/Users/scott/dev/opensource/netbeans/nbbuild/build.xml:633: The following error 
occurred while executing this line:
/Users/scott/dev/opensource/netbeans/nbbuild/build.xml:628: The following error 
occurred while executing this line:
/Users/scott/dev/opensource/netbeans/nbbuild/build.xml:675: The following error 
occurred while executing this line:
/Users/scott/dev/opensource/netbeans/nbbuild/templates/projectized.xml:153: 
Cannot compile against a module: 
/Users/scott/dev/opensource/netbeans/nbbuild/netbeans/ide/modules/libs-c-kohlschutter-junixsocket.jar
 because of dependency: libs.c.kohlschutter.junixsocket/2 > 3.0

The patch is trivial, but of course I want to build and test before submitting 
a PR…

Did I miss something?

Scott

Re: Bad sample code in Formatting preferences for Java

[Scott Palmer]

> On Nov 28, 2022, at 1:58 PM, Michael Bien  wrote:
> 
> On 28.11.22 20:00, Neil C Smith wrote:
>> On Mon, 28 Nov 2022 at 18:55, Scott Palmer > <mailto:swpal...@gmail.com>> wrote:
>>> In preferences/settings under Editor, Formatting, language Java, category 
>>> Spaces:
>>> 
>>> The sample code used has a misplaced closing brace.  Instead of closing the 
>>> ‘meth’ method it is after the following “add” method, ending the example 
>>> with a double “} }” on the same line.
>> So it does.  Can you open a GH issue?
> 
> or PR :)


Issue 5023 filed.  
PR to come, I hope... we’ll see how the fight with git goes. (I use Mercurial 
because I’m not a masochist :-). )

Scott

Bad sample code in Formatting preferences for Java

[Scott Palmer]

In preferences/settings under Editor, Formatting, language Java, category 
Spaces:

The sample code used has a misplaced closing brace.  Instead of closing the 
‘meth’ method it is after the following “add” method, ending the example with a 
double “} }” on the same line.

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

Re: [VOTE] Release Apache NetBeans 16 Windows installer

[Scott Palmer]

+1 (non-binding)

On Mon, Nov 28, 2022 at 8:41 AM Kai Uwe Pel  wrote:

> +1 (non-binding)
>
>
> Cheers
> Kai Uwe Pel
>
> On 11/23/2022 2:45 PM, Eric Barboni wrote:
> > As main Apache NetBeans 16 vote is having +1 binding vote, let's start
> vote
> > for Apache NetBeans 16 Windows installer.
> >
> > Primary voting artefact :
> >
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-installers/16/Apach
> > e-NetBeans-16-bin-windows-x64.exe
> >
> > SHA512 checksum :
> >
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-installers/16/Apach
> > e-NetBeans-16-bin-windows-x64.exe.sha512
> >
> >
> 0999661d46eb809207a97e5747ba13036459c8e037d070f4eaa0db4788900d5940979697015e
> > 17b8da5e4d74fb5f418df578181d6aefe0e75236040c474dc551
> >
> > KEYS file :
> > https://dist.apache.org/repos/dist/release/netbeans/KEYS
> >
> > PGP signature file :
> >
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-installers/16/Apach
> > e-NetBeans-16-bin-windows-x64.exe.asc
> >
> > Built by Jenkins job :
> >
> https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/netbeans/job/
> > release160/11/
> >
> > This vote is going to be open at least 72 hours, vote with +1, 0, and -1
> as
> > usual. Please mark your vote with (binding) if you're an Apache,NetBeans
> PMC
> > member.
> >
> > This vote is dependent on the main Apache NetBeans 16 release vote
> passing.
> >
> > Best Regards
> > Eric
> >
> >
> > -
> > 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: NetBEans 16-rc4 - More Gradle weirdness

[Scott Palmer]

Another FYI...
Hopefully someday these class version issues will be less common.  There is
a proposed API for the JDK that could reduce the need for libraries like
ASM, but it will be a while before it is public (assuming it is accepted)
and projects like Gradle and NetBeans would be able to use it.
https://openjdk.org/jeps/8280389


On Sat, Nov 26, 2022 at 12:38 PM Laszlo Kishalmi 
wrote:

> Well. the Gradle Tooling API is said to be backward and forward
> compatible with Gradle and JDK versions.
>
> On 11/26/22 05:21, Neil C Smith wrote:
> > On 11/25/22 15:27, Michael Bien wrote:
> >> there is wip in this area for NB17:
> >> https://github.com/apache/netbeans/pull/4985
> > Yes, following with interest!  The problem in #4944 is slightly
> > different though.  Is the Gradle Tooling API itself immune to the
> > problem of running on future JDKs?
> >
> > On Sat, 26 Nov 2022 at 00:47, Laszlo Kishalmi 
> wrote:
> >> I'm thinking about a patch release for Gradle Support for NB16...
> > Great!  I wish we could make the pushing updates process a little easier
> ...
> >
> > Best wishes,
> >
> > Neil
> >
> > -
> > 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: NetBEans 16-rc4 - More Gradle weirdness

[Scott Palmer]

Just FYI, Gradle 7.6 was released on Nov 25th.

+1 to a patch release.

On Sat, Nov 26, 2022 at 8:21 AM Neil C Smith  wrote:

> On 11/25/22 15:27, Michael Bien wrote:
> > there is wip in this area for NB17:
> > https://github.com/apache/netbeans/pull/4985
>
> Yes, following with interest!  The problem in #4944 is slightly
> different though.  Is the Gradle Tooling API itself immune to the
> problem of running on future JDKs?
>
> On Sat, 26 Nov 2022 at 00:47, Laszlo Kishalmi 
> wrote:
> > I'm thinking about a patch release for Gradle Support for NB16...
>
> Great!  I wish we could make the pushing updates process a little easier
> ...
>
> Best wishes,
>
> Neil
>
> -
> 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: NetBEans 16-rc4 - More Gradle weirdness

[Scott Palmer]

Stupid GMail sent the message before I was done...
The rest of the error says:
"phase 'semanic anaylisis' in source unit '__BuildScript_' Unsupported
major class version 63"

I.e. it is trying to use Gradle 7.5 while NetBeans is running on JDK 19 and
failing.

What is interesting is the first message - that Java 19 is not supported by
Gradle 7.6.  That is false.  7.6 is when Gradle gets Java 19 support.  The
suggestion to downgrade to 7.5 which is known not to work is a little funny.

Basically the release notes for NetBeans 16 should mention that Gradle
projects don't work if you run the IDE with JDK 19, JDK 17 should be used
instead.


Regards, scott


> My .java files show a hint on the first line:
>
> "Missing mandatory Classpath entries. Resolve Project Problems."
>
> The "Resolve Project Problems" dialog has two entries:
>
> The first is: "Unsupported Java Runtime" which shows the text:
>
> The IDE is running on Java 19 that is not supported by Gradle 7.6.
> The IDE will attempt to use Gradle 7.5 to gather the project information.
>
> Either upgrade your Gradle version on your project or run the IDE on Java
> 18 to avoid this problem!
>
> The next is the usual "Priming Build Required", the priming build always
> fails with (and I really wish I could copy paste this message, but it isn't
> selectable):
>
> "Could not open cp_init generic class cache for initialization script
> '/Users/scott/Library/Caches/NetBeans/16-rc4/gradle/nb-tooling.gradle'
> (/Users/scott/.gradle/caches/7.5/scripts/7xonayhtu59gy36tmrwmb6dqe). BUG!
> exception is phase "
>

NetBEans 16-rc4 - More Gradle weirdness

[Scott Palmer]

My .java files show a hint on the first line:

"Missing mandatory Classpath entries. Resolve Project Problems."

The "Resolve Project Problems" dialog has two entries:

The first is: "Unsupported Java Runtime" which shows the text:

The IDE is running on Java 19 that is not supported by Gradle 7.6.
The IDE will attempt to use Gradle 7.5 to gather the project information.

Either upgrade your Gradle version on your project or run the IDE on Java
18 to avoid this problem!

The next is the usual "Priming Build Required", the priming build always
fails with (and I really wish I could copy paste this message, but it isn't
selectable):

"Could not open cp_init generic class cache for initialization script
'/Users/scott/Library/Caches/NetBeans/16-rc4/gradle/nb-tooling.gradle'
(/Users/scott/.gradle/caches/7.5/scripts/7xonayhtu59gy36tmrwmb6dqe). BUG!
exception is phase "

NB 16-rc4 Gradle project issues with JDK-19 and Gradle 7.6.-rc3

[Scott Palmer]

Running NB 16-rc4 on JDK 19
Gradle set to use 7.6-rc3
I get this error reported:

Could not open cp_init generic class cache for initialization script
'/Users/scott/Library/Caches/NetBeans/16-rc4/gradle/nb-tooling.gradle'
(/Users/scott/.gradle/caches/7.5/scripts/7xonayhtu59gy36tmrwmb6dqe). BUG!
exception in phase semantic analysis' in source unit '_BuildScript_'
Unsupported class file major version 63

Looks like Gradle 7.5 is being used internally, but since we are running on
JDK 19 it fails?

Scott

NetBeans cache directory X seems to be abandoned - Removal silently fails on Windows 11

[Scott Palmer]

I just finished going through about a dozen abandoned cache directories
that the Janitor Scan identified and told NB to remove them all.
(Tediously, one at a time.  It would be better if when I clicked on the
message for one of them, they could all be listed in a single "Janitor
Scan" dialog so I could select them all and wipe them out in one go.)

However, I then ran into another issue that got me to quit NB and restart
it.  When I restarted NB the Janitor Scan found all the same abandoned
cache folders!
The removal failed for every one.  The directories appear to be untouched.
Nothing relevant shows in messages.log

It doesn't appear to be permissions related, as the directories can be
deleted or put in the recycle bin without any need to get extra permissions.

Regards,

Scott

Re: NB RC-3 Gradle Issues

[Scott Palmer]

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

[Scott Palmer]

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

[Scott Palmer]

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

Are the native libraries needed?

[Scott Palmer]

I tried to run NB RC-3 from the binary zip on macOS 12.6.1 (Monterey) and got a 
security notice that it would refuse to load libjnidispatch-nb.jnilib because 
it was downloaded from the internet and the developer couldn’t be verified.  
This appears to be simply because the binaries are not signed for the RC builds.

But I got to wondering what it is for?  The IDE seemed to start up without 
issues anyway.

I see the following .jnilib files:

~/netbeans/platform/modules/lib/aarch64/libjnidispatch-nb.jnilib
~/netbeans/platform/modules/lib/x86_64/libjnidispatch-nb.jnilib
~/netbeans/profiler/lib/deployed/jdk16/mac/libprofilerinterface.jnilib
~/netbeans/profiler/lib/deployed/jdk15/mac/libprofilerinterface.jnilib

Am I correct in assuming the JDK 16 profiler interface library works on JDK 
17-19 as well?  I see there isn’t a corresponding library for pre JDK 15, and 
there isn’t anything for aarch64 vs x86_ 64 so I’m not sure what it’s all about 
(is it a “fat” binary?).

There are also:

~/netbeans/ide/bin/nativeexecution/MacOSX-x86/unbuffer.dylib
~/netbeans/ide/bin/nativeexecution/MacOSX-x86_64/unbuffer.dylib
~/netbeans/ide/modules/lib/aarch64/libjunixsocket-native-2.5.1.dylib
~/netbeans/ide/modules/lib/x86_64/libjunixsocket-native-2.5.1.dylib

I have no idea what they are for. I didn’t get any notice about them not being 
verified, so I presume they aren’t needed for most tasks.


Regards,

Scott


P.S. >  For anyone else on macOS that isn’t already aware.  The following 
command will remove the quarantine status:

  xattr -d com.apple.quarantine 
~/netbeans/platform/modules/lib/x86_64/libjnidispatch-nb.jnilib
-
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: [DISCUSS] tweak some defaults for NB17?

[Scott Palmer]

On Thu, Nov 3, 2022 at 12:31 PM Neil C Smith  wrote:
...

> Well, one lesson is making clear where the settings are when we change
> defaults, so that those who preferred the way things were know how to
> revert.
>

On that note, while reading this thread I decided to try the small icons
for myself... It took me a while to find the option because my first
instinct was to go to the preferences panel and find it on the Look and
Feel section.  Not finding it there, I searched the General section and
anything else, but the option isn't there!  I finally found it by
right-clicking the toolbar. I think it's great that it is available from
the toolbar context menu, but that option should also be found in the
Preferences dialog.

(I then reverted that change because the small toolbar icons are too small
for me.  Keep the default as it is.)

Scott

Problems/Exceptions with NB 16 RC-2

[Scott Palmer]

After waiting way too long for a ctrl-click to "Go to Declaration" to
finish, I noticed the following exception, which doesn't make sense. (can't
find java.lang package?)
"Go to Declaration" took nearly 30s, got the "long operation..." popup.
The IDE has been open with this project for days, indices should be up to
date etc.. I can't figure out why it would take so long.

*Product Version:* Apache NetBeans IDE 16-rc2

*Java:* 17.0.5; OpenJDK 64-Bit Server VM 17.0.5+8-LTS

*Runtime:* OpenJDK Runtime Environment 17.0.5+8-LTS

*System:* Windows 11 version 10.0 running on amd64; Cp1252; en_CA (nb)


com.sun.tools.javac.code.Symbol$CompletionFailure: cannot find symbol
  symbol: package java.lang
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
at
org.netbeans.lib.nbjavac.services.NBClassFinder.lambda$getCompleter$1(NBClassFinder.java:104)
at com.sun.tools.javac.code.Symbol.complete(Symbol.java:682)
at com.sun.tools.javac.code.Symbol$PackageSymbol.members(Symbol.java:1176)
at
com.sun.tools.javac.code.Symbol$ModuleSymbol.getEnclosedElements(Symbol.java:1082)
at
com.sun.tools.javac.code.Symbol$ModuleSymbol.getEnclosedElements(Symbol.java:962)
at
org.netbeans.modules.java.hints.bugs.NPECheck$VisitorImpl.visitMethod(NPECheck.java:1154)
at
org.netbeans.modules.java.hints.bugs.NPECheck$VisitorImpl.visitMethod(NPECheck.java:546)
at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:944)
at com.sun.source.util.TreeScanner.scan(TreeScanner.java:92)
at
org.netbeans.api.java.source.support.CancellableTreeScanner.scan(CancellableTreeScanner.java:69)
at
org.netbeans.modules.java.hints.bugs.NPECheck$VisitorImpl.scan(NPECheck.java:648)
at
org.netbeans.modules.java.hints.bugs.NPECheck$VisitorImpl.scan(NPECheck.java:546)
at com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:96)
at com.sun.source.util.TreeScanner.scan(TreeScanner.java:111)
at
org.netbeans.api.java.source.support.CancellableTreeScanner.scan(CancellableTreeScanner.java:78)
at com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:119)
at com.sun.source.util.TreeScanner.visitClass(TreeScanner.java:203)
at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:851)
at com.sun.source.util.TreeScanner.scan(TreeScanner.java:92)
at
org.netbeans.api.java.source.support.CancellableTreeScanner.scan(CancellableTreeScanner.java:69)
at
org.netbeans.modules.java.hints.bugs.NPECheck$VisitorImpl.scan(NPECheck.java:648)
at
org.netbeans.modules.java.hints.bugs.NPECheck$VisitorImpl.scan(NPECheck.java:546)
at com.sun.source.util.TreeScanner.scan(TreeScanner.java:111)
at
org.netbeans.api.java.source.support.CancellableTreeScanner.scan(CancellableTreeScanner.java:78)
at com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:119)
at
com.sun.source.util.TreeScanner.visitCompilationUnit(TreeScanner.java:152)
at com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:619)
at com.sun.source.util.TreeScanner.scan(TreeScanner.java:92)
at
org.netbeans.api.java.source.support.CancellableTreeScanner.scan(CancellableTreeScanner.java:69)
at
org.netbeans.modules.java.hints.bugs.NPECheck$VisitorImpl.scan(NPECheck.java:648)
at
org.netbeans.modules.java.hints.bugs.NPECheck.computeExpressionsState(NPECheck.java:503)
at
org.netbeans.modules.java.hints.bugs.NPECheck.methodInvocation(NPECheck.java:308)
at jdk.internal.reflect.GeneratedMethodAccessor116.invoke(Unknown Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
[catch] at
org.netbeans.modules.java.hints.providers.code.CodeHintProviderImpl$WorkerImpl.createErrors(CodeHintProviderImpl.java:315)
at
org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker.runHint(HintsInvoker.java:794)
at
org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker.access$400(HintsInvoker.java:89)
at
org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker$ScannerImpl.runAndAdd(HintsInvoker.java:656)
at
org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker$ScannerImpl.scan(HintsInvoker.java:675)
at
org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker$ScannerImpl.scan(HintsInvoker.java:609)
at com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:96)
at com.sun.source.util.TreeScanner.visitVariable(TreeScanner.java:243)
at com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:1036)
at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:92)
at

Re: Netbeans 16-rc2 Java Editor Bug

[Scott Palmer]

Ah.. well it seems this is caused by an incomplete brace in code
that follows, but several lines away.  So I understand what NB is trying to
do, it is just unexpected in the immediate context.

Basically I had a large method that was in the process of being edited and
was missing its final closing brace.   I was adding a condition near the
beginning of the method and observed this happening.
I'm not sure if it is worth doing anything about, though it was irritating
until I realized why it was happening.

Cheers,

SCott

On Fri, Oct 28, 2022 at 12:00 PM Scott Palmer  wrote:

> I just noticed that there is an issue with NetBeans inserting an extra }
> character while editing Java code.
>
> If I type the following:
>
>   if (someCondition) {}
>
> Then I place the cursor between the braces { | } and hit enter, the result
> is:
>
>   if (someCondition) {
> |
>   }}
>
> (Where | is the cursor location before and after)
>
> Note the extra closing brace.
>
> Scott
>
>

Netbeans 16-rc2 Java Editor Bug

[Scott Palmer]

I just noticed that there is an issue with NetBeans inserting an extra }
character while editing Java code.

If I type the following:

  if (someCondition) {}

Then I place the cursor between the braces { | } and hit enter, the result
is:

  if (someCondition) {
|
  }}

(Where | is the cursor location before and after)

Note the extra closing brace.

Scott

Re: nb-javac for building NetBeans itself

[Scott Palmer]

JDK 8 is still supported by Oracle.  Dropping it should happen when it makes 
sense, after support  has ended.  If you need to work on Java versions prior to 
8, first, I’m sorry, you have my sympathy, second, download an older version of 
NetBeans that supports it - if you are living in the past go all-in. :-)

I still have to make Java 8 compatible output for some projects.  If that means 
I have to use NB 16 or 15 instead of 17, so be it.  I would absolutely not want 
NB to be held back by a need to support ancient tech.  Microsoft does that with 
Windows and we are still living with the insanity of DOS drive letters and path 
limits because of it!

From the sounds of it, nb-javac is a relic that shouldn’t be needed… cut it 
out.  Tooling (Maven/Gradle) can support alternative compilers in some cases… 
maybe if those compilers are compatible with the javac API they can integrate 
with NB for better editor feedback or whatever. If someone wants to support 
nb-javac as an optional plugin fine, but overall the platform needs to move 
forward, not hold on to the past.  Apache shouldn’t directly concern itself 
with nb-javac anymore.

Changes is inevitable, resistance is futile, etc…  I’m much more interested in 
top-notch Java 20+ support.  I think it is reasonable to say that NB supports 
the oldest LTS JDK and no earlier.

Just my opinion,

Scott

> On Oct 26, 2022, at 6:57 PM, Geertjan Wielenga 
>  wrote:
> 
> Just been looking into open source work done in the context of the
> European Union and one of the key applications there requires JDK 8:
> 
> https://github.com/l-e-x/leos
> 
> I.e., we need to stop thinking that Java 8 is somehow dead or
> ethically or otherwise problematic -- it's simply what a great deal of
> applications use and any strategy we come up with needs to cater to
> Java 8.
> 
> Gj
> 
> On Wed, Oct 26, 2022 at 10:57 PM Glenn Holmer
>  wrote:
>> 
>> On 10/25/22 22:48, Laszlo Kishalmi wrote:
>>> I'm confused as well. Still not clear, what are we about to solve here.
>>> Use new lang spec with old runtimes? I do not have granny issues...
>> 
>> Also confused. If this is all so people can still code for Java 8 in
>> this day and age, I say drop support for JDK8 ("Nuke the site from
>> orbit, it's the only way to be sure"). I may be out of touch, being
>> retired for eight years now, but IMHO anyone still using Java 8 would be
>> better off to stay in his parents' basement with his VAX-11 coding
>> assembly language. It's getting as bad as the Python 2/3 thing was.
>> 
>> And if it's so you can code using new features not available in the JDK
>> you're using... use the newer JDK! I just don't understand any of this,
>> but I do remember a time when NetBeans was the leader in out-of-box
>> support for new language features.
>> 
>>> The examples of Java 17 has no support for Java 6 target, makes this
>>> discussion ridiculous.
>> 
>> +1, what are we even talking about here? Java 6? seriously?
>> 
>> --
>> Glenn Holmer (Linux registered user #16682)
>> "After the vintage season came the aftermath -- and Cenbe."
>> 
>> 
>> 
>> -
>> 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
> 
> 
> 


-
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

NB 16rc-1 exception during refactoring

[Scott Palmer]

Got this exception while doing some refactoring... I'm not sure what caused
it, as other refactorings of exactly the same type, moving a class from one
package to another (with same source and destination) worked without seeing
this.  Refactored by dragging the java files from one package to another in
the project tree view.

java.lang.NullPointerException: Cannot invoke
"javax.tools.JavaFileObject.isNameCompatible(String,
javax.tools.JavaFileObject$Kind)" because "tree.sourcefile" is null
at com.sun.tools.javac.tree.TreeInfo.isModuleInfo(TreeInfo.java:1286)
at org.netbeans.lib.nbjavac.services.NBEnter.visitTopLevel(NBEnter.java:67)
at com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:549)
at com.sun.tools.javac.comp.Enter.classEnter(Enter.java:286)
at com.sun.tools.javac.comp.Enter.classEnter(Enter.java:301)
at com.sun.tools.javac.comp.Enter.complete(Enter.java:603)
at
com.sun.tools.javac.main.JavaCompiler.readSourceFile(JavaCompiler.java:821)
at
com.sun.tools.javac.main.JavaCompiler.readSourceFile(JavaCompiler.java:778)
at com.sun.tools.javac.main.JavaCompiler.lambda$new$0(JavaCompiler.java:341)
at com.sun.tools.javac.code.ClassFinder.fillIn(ClassFinder.java:378)
at com.sun.tools.javac.code.ClassFinder.complete(ClassFinder.java:303)
at
org.netbeans.lib.nbjavac.services.NBClassFinder.lambda$getCompleter$1(NBClassFinder.java:95)
at com.sun.tools.javac.code.Symbol.complete(Symbol.java:682)
at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1410)
at com.sun.tools.javac.code.Symbol.apiComplete(Symbol.java:688)
at
com.sun.tools.javac.code.Symbol$TypeSymbol.getEnclosedElements(Symbol.java:859)
at
com.sun.tools.javac.code.Symbol$TypeSymbol.getEnclosedElements(Symbol.java:797)
at
org.netbeans.modules.java.hints.bugs.NPECheck$VisitorImpl.visitMethod(NPECheck.java:1154)
at
org.netbeans.modules.java.hints.bugs.NPECheck$VisitorImpl.visitMethod(NPECheck.java:546)
at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:944)
at com.sun.source.util.TreeScanner.scan(TreeScanner.java:92)
at
org.netbeans.api.java.source.support.CancellableTreeScanner.scan(CancellableTreeScanner.java:69)
at
org.netbeans.modules.java.hints.bugs.NPECheck$VisitorImpl.scan(NPECheck.java:648)
at
org.netbeans.modules.java.hints.bugs.NPECheck$VisitorImpl.scan(NPECheck.java:546)
at com.sun.source.util.TreeScanner.scan(TreeScanner.java:111)
at
org.netbeans.api.java.source.support.CancellableTreeScanner.scan(CancellableTreeScanner.java:78)
at com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:119)
at com.sun.source.util.TreeScanner.visitClass(TreeScanner.java:203)
at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:851)
at com.sun.source.util.TreeScanner.scan(TreeScanner.java:92)
at
org.netbeans.api.java.source.support.CancellableTreeScanner.scan(CancellableTreeScanner.java:69)
at
org.netbeans.modules.java.hints.bugs.NPECheck$VisitorImpl.scan(NPECheck.java:648)
at
org.netbeans.modules.java.hints.bugs.NPECheck$VisitorImpl.scan(NPECheck.java:546)
at com.sun.source.util.TreeScanner.scan(TreeScanner.java:111)
at
org.netbeans.api.java.source.support.CancellableTreeScanner.scan(CancellableTreeScanner.java:78)
at com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:119)
at
com.sun.source.util.TreeScanner.visitCompilationUnit(TreeScanner.java:152)
at com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:619)
at com.sun.source.util.TreeScanner.scan(TreeScanner.java:92)
at
org.netbeans.api.java.source.support.CancellableTreeScanner.scan(CancellableTreeScanner.java:69)
at
org.netbeans.modules.java.hints.bugs.NPECheck$VisitorImpl.scan(NPECheck.java:648)
at
org.netbeans.modules.java.hints.bugs.NPECheck.computeExpressionsState(NPECheck.java:503)
at
org.netbeans.modules.java.hints.bugs.NPECheck.methodInvocation(NPECheck.java:308)
at jdk.internal.reflect.GeneratedMethodAccessor100.invoke(Unknown Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
[catch] at
org.netbeans.modules.java.hints.providers.code.CodeHintProviderImpl$WorkerImpl.createErrors(CodeHintProviderImpl.java:315)
at
org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker.runHint(HintsInvoker.java:794)
at
org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker.access$400(HintsInvoker.java:89)
at
org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker$ScannerImpl.runAndAdd(HintsInvoker.java:656)
at
org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker$ScannerImpl.scan(HintsInvoker.java:675)
at
org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker$ScannerImpl.scan(HintsInvoker.java:609)
at
com.sun.source.util.TreeScanner.visitExpressionStatement(TreeScanner.java:502)
at
com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1594)
at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:92)
at

Re: Copy Paste still an issue

[Scott Palmer]

No Docker, No containers.  Just a normal Windows install running directly
on a Windows PC/laptop. The problem is intermittent and reported by many.
I am not convinced that it isn't a general problem for all Windows users,
most cut and paste happens entirely within the IDE after all - that always
works. It's only pasting to or from an external app that has an issue -
sometimes.  When it happens, it continues to happen until a copy is made
from a non-editor window within NetBeans, e.g. the About dialog, or
NetBeans is restarted.  When it doesn't happen, no amount of repeated
copy/paste will trigger it on-demand.  It sneaks up on you.  I usually have
Nb running for many days at a time... then every so often I will try to
copy something to an email, or from a web page or terminal and suddenly
it's not working.

I'm going to try Laszlo's patch, though it will take running for a
long time to have confidence that the problem isn't there.


Scott


On Wed, Aug 31, 2022 at 2:46 PM Peter Blemel  wrote:

>
> If I may chime in, if the JRE/JDK and NetBeans are the same and the
> problem isn't reproducible then I would suggest first determining what
> might be different between this user's environment and others where the
> problem doesn't present itself. For example, confirming that this user's
> NetBeans isn't inside of a container like Docker or AppImage that might be
> sitting between the Windows clipboard <-> NetBeans and preventing clipboard
> transfers as part of some sort of security policy.  This may not be the
> case, but it seems like a suspect to eliminate in any case.
>
> Regards,
> Peter
>
> 
> From: László Kishalmi 
> Sent: Wednesday, August 31, 2022 12:23 PM
> To: dev@netbeans.apache.org 
> Subject: Re: Copy Paste still an issue
>
> Well, it is ok to test it even if you do not have clipboard issues. Just to
> make sure it does not make Windows Clipboard usability worse.
>
> Also as this is a platform code, tests NetBeans running on JDK 8 are
> welcome as well.
>
> On Wed, Aug 31, 2022 at 11:15 AM Christian Lenz 
> wrote:
>
> > I’m using Windows but can someone please give an exact reproducable case,
> > where I can test it on my machine to test the PR too?
> >
> >
> > Cheers
> >
> > Chris
> >
> > Von: László Kishalmi
> > Gesendet: Mittwoch, 31. August 2022 20:05
> > An: dev@netbeans.apache.org
> > Betreff: Re: Copy Paste still an issue
> >
> > Well, I'm lucky enough not having Windows around.
> > Though it seems we did a lot of hacks around the clipboard in the early
> > ages, in order to work around AWT/Native clipboard issues.
> > There are a chance that the AWT/Native situation has improved over the
> > years and our hacks become a source of nasty bugs.
> >
> > My suspect would be:
> >
> >
> https://github.com/apache/netbeans/blob/a8f7024d72051006c124489430a961afbcdf346a/platform/o.n.bootstrap/src/org/netbeans/NbClipboard.java#L344
> >
> > Well someone brave enough having Clipboard issues on Windows might try
> this
> > one:
> > https://github.com/apache/netbeans/pull/4572
> >
> >
> >
> > On Wed, Aug 31, 2022 at 9:16 AM Scott Palmer  wrote:
> >
> > > It’s an intermittent issue on Windows that has been around for a long
> > time.
> > >
> > > Edit the netbeans.conf file in netbeans/etc/ to add:
> > >  -J-Dorg.netbeans.NbClipboard.level=FINEST
> > >
> > > I keep forgetting after installing new versions :-(
> > >
> > > That may provide needed details in the logs.
> > >
> > > Hopefully we can get this sorted… It’s been a thorn in my side for
> years.
> > >
> > >
> > > Scott
> > >
> > > > On Aug 31, 2022, at 11:13 AM, Neil C Smith 
> > > wrote:
> > > >
> > > > On Wed, 31 Aug 2022 at 15:51, Kenneth Fogel <
> > kfo...@dawsoncollege.qc.ca>
> > > wrote:
> > > >> That I am not the only one who comes across this issue leads me to
> > > believe it is not a 'just on my machine' problem.
> > > >
> > > > It is definitely not just on your machine, but it is also not on
> every
> > > > machine.  The bug linked previously has a bunch of questions and a
> > > > link to a previous thread on here with flags and things to test.
> > > >
> > > > Out of interest, what shows with CTRL_SHIFT-D (paste from history)?
> > > >
> > > > Until someone working on the IDE can reproduce the circumstances of
> > > > this issue, I don't see it getting fixed.
> > > >
> >

Re: Copy Paste still an issue

[Scott Palmer]

On Wed, Aug 31, 2022 at 2:46 PM Peter Blemel  wrote:

>
> If I may chime in, if the JRE/JDK and NetBeans are the same and the
> problem isn't reproducible then I would suggest first determining what
> might be different between this user's environment and others where the
> problem doesn't present itself. For example, confirming that this user's
> NetBeans isn't inside of a container like Docker or AppImage that might be
> sitting between the Windows clipboard <-> NetBeans and preventing clipboard
> transfers as part of some sort of security policy.  This may not be the
> case, but it seems like a suspect to eliminate in any case.
>
> Regards,
> Peter
>
> 
> From: László Kishalmi 
> Sent: Wednesday, August 31, 2022 12:23 PM
> To: dev@netbeans.apache.org 
> Subject: Re: Copy Paste still an issue
>
> Well, it is ok to test it even if you do not have clipboard issues. Just to
> make sure it does not make Windows Clipboard usability worse.
>
> Also as this is a platform code, tests NetBeans running on JDK 8 are
> welcome as well.
>
> On Wed, Aug 31, 2022 at 11:15 AM Christian Lenz 
> wrote:
>
> > I’m using Windows but can someone please give an exact reproducable case,
> > where I can test it on my machine to test the PR too?
> >
> >
> > Cheers
> >
> > Chris
> >
> > Von: László Kishalmi
> > Gesendet: Mittwoch, 31. August 2022 20:05
> > An: dev@netbeans.apache.org
> > Betreff: Re: Copy Paste still an issue
> >
> > Well, I'm lucky enough not having Windows around.
> > Though it seems we did a lot of hacks around the clipboard in the early
> > ages, in order to work around AWT/Native clipboard issues.
> > There are a chance that the AWT/Native situation has improved over the
> > years and our hacks become a source of nasty bugs.
> >
> > My suspect would be:
> >
> >
> https://github.com/apache/netbeans/blob/a8f7024d72051006c124489430a961afbcdf346a/platform/o.n.bootstrap/src/org/netbeans/NbClipboard.java#L344
> >
> > Well someone brave enough having Clipboard issues on Windows might try
> this
> > one:
> > https://github.com/apache/netbeans/pull/4572
> >
> >
> >
> > On Wed, Aug 31, 2022 at 9:16 AM Scott Palmer  wrote:
> >
> > > It’s an intermittent issue on Windows that has been around for a long
> > time.
> > >
> > > Edit the netbeans.conf file in netbeans/etc/ to add:
> > >  -J-Dorg.netbeans.NbClipboard.level=FINEST
> > >
> > > I keep forgetting after installing new versions :-(
> > >
> > > That may provide needed details in the logs.
> > >
> > > Hopefully we can get this sorted… It’s been a thorn in my side for
> years.
> > >
> > >
> > > Scott
> > >
> > > > On Aug 31, 2022, at 11:13 AM, Neil C Smith 
> > > wrote:
> > > >
> > > > On Wed, 31 Aug 2022 at 15:51, Kenneth Fogel <
> > kfo...@dawsoncollege.qc.ca>
> > > wrote:
> > > >> That I am not the only one who comes across this issue leads me to
> > > believe it is not a 'just on my machine' problem.
> > > >
> > > > It is definitely not just on your machine, but it is also not on
> every
> > > > machine.  The bug linked previously has a bunch of questions and a
> > > > link to a previous thread on here with flags and things to test.
> > > >
> > > > Out of interest, what shows with CTRL_SHIFT-D (paste from history)?
> > > >
> > > > Until someone working on the IDE can reproduce the circumstances of
> > > > this issue, I don't see it getting fixed.
> > > >
> > > > Best wishes,
> > > >
> > > > Neil
> > > >
> > > > -
> > > > 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: Copy Paste still an issue

[Scott Palmer]

It’s an intermittent issue on Windows that has been around for a long time.

Edit the netbeans.conf file in netbeans/etc/ to add:
 -J-Dorg.netbeans.NbClipboard.level=FINEST

I keep forgetting after installing new versions :-(

That may provide needed details in the logs.

Hopefully we can get this sorted… It’s been a thorn in my side for years.


Scott

> On Aug 31, 2022, at 11:13 AM, Neil C Smith  wrote:
> 
> On Wed, 31 Aug 2022 at 15:51, Kenneth Fogel  
> wrote:
>> That I am not the only one who comes across this issue leads me to believe 
>> it is not a 'just on my machine' problem.
> 
> It is definitely not just on your machine, but it is also not on every
> machine.  The bug linked previously has a bunch of questions and a
> link to a previous thread on here with flags and things to test.
> 
> Out of interest, what shows with CTRL_SHIFT-D (paste from history)?
> 
> Until someone working on the IDE can reproduce the circumstances of
> this issue, I don't see it getting fixed.
> 
> Best wishes,
> 
> Neil
> 
> -
> 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: API snapshot review for NetBeans 15 - possible issue?

[Scott Palmer]

The entire way those bit shifts are coded is error prone.

Should be:

/** Operating system is Windows NT. */
 public static final int OS_WINNT = 1 << 0;
 /** Operating system is Solaris. */
 public static final int OS_SOLARIS = 1 << 1;
 public static final int OS_SOLARIS = 1 << 3;
 /** Operating system is Linux. */
 public static final int OS_LINUX = 1 << 4;
   …

Not using references to earlier constants and only changing the amount of the 
shift.  Makes it easier to read and see whaat the actual value should be.  It’s 
clear that each value represents a single bit without having to go back to see 
what the original value was, and removing any of the constants will never cause 
subsequent values to change. Maybe add a comment that 1 << 2 is skipped for 
whatever reason.  Perhaps leave a comment documenting the old w95/98 values so 
we know why those values aren’t used anymore.

Scott


> On Aug 11, 2022, at 12:48 PM, László Kishalmi  
> wrote:
> 
> Anyway, here it is. I hope it helps:
> https://github.com/apache/netbeans/pull/4497
> 
> On Thu, Aug 11, 2022 at 9:15 AM László Kishalmi 
> wrote:
> 
>> OMG!
>> Just had some time to look at this. Unfortunately, I think it is serious.
>> Due to wrong bit-shifts the id-s for MAC_OS and LINUX has been changed,
>> which would mean a serious incompatibility as AFAIK the compiler puts
>> actual value of these fields into the bytecode.
>> That would cause third-party plugin compatibility issues whenever the
>> plugin would use those constants directly.
>> I hate to say it, but I think it is a reason for RC4
>> 
>> Do we have a PR fixing those bit-shifts or shall I create one?
>> 
>> On Wed, Aug 10, 2022 at 1:34 AM Neil C Smith 
>> wrote:
>> 
>>> Hi,
>>> 
>>> I generated the API snapshot sigtest file for review yesterday.
>>> Ideally we need to review earlier in the release process, but for a
>>> number of reasons they haven't been generated until now ...
>>> 
>>> https://github.com/apache/netbeans/pull/4487
>>> 
>>> One thing that stands out to me is the changes in compile time
>>> constants inside Utilities introduced by
>>> https://github.com/apache/netbeans/pull/4025
>>> 
>>> I'm not sure how much of an issue that might be in practice, and
>>> whether it's a reason to run an rc4?  Review welcomed!
>>> 
>>> Thanks,
>>> 
>>> Neil
>>> 
>>> -
>>> 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: 12.4 Can we fix cut and paste before release?

[Scott Palmer]

Well I installed NB14 and forgot to add
-J-Dorg.netbeans.NbClipboard.level=FINEST to the conf file and of
course the clipboard has failed twice already...

So frustrating. Why does it happen exactly when I don't have the logging
enabled?  Perhaps that is a clue, maybe the logging affects some race
condition? I don't know.

Scott

On Fri, Aug 6, 2021 at 11:27 AM Geertjan Wielenga
 wrote:

> will/won’t have.
>
> Start with a fresh userdir and a standard NetBeans.conf, just with
> -J-Dorg.netbeans.NbClipboard.level=FINEST.
>
> Then Neil can investigate since he nor I nor others wanting to help can
> reproduce this so far.
>
> Gj
>
> On Fri, 6 Aug 2021 at 17:24, Geertjan Wielenga <
> geertjan.wiele...@googlemail.com> wrote:
>
> > Indeed, please test without settings that regular installs will have.
> >
> > Gj
> >
> > On Fri, 6 Aug 2021 at 17:22, Scott Palmer  wrote:
> >
> >> Thanks,
> >>
> >> I’ve updated my netbeans.conf file to have
> >> -J-Dorg.netbeans.NbClipboard.level=FINEST as well as
> >> -J-Dnetbeans.slow.system.clipboard.hack=false
> >> Though I should probably test without that last property as well, as it
> >> isn’t what regular installs will have.
> >>
> >> I’m just doing whatever I can to avoid the frustration of a broken
> >> clipboard at this point though.  You can imagine how infuriating it is
> when
> >> something so basic just stops working when you need it.  Restarting the
> IDE
> >> so I can paste something is rather disruptive.
> >>
> >> Cheers,
> >>
> >> Scott
> >>
> >>
> >> > On Aug 6, 2021, at 9:54 AM, Neil C Smith 
> wrote:
> >> >
> >> > On Fri, 6 Aug 2021 at 04:23, Scott Palmer  wrote:
> >> >> It would be great if the clipboard would work on Windows for NetBeans
> >> 12.5
> >> >
> >> > Yes, although that would involve understanding what's broken.  Just
> >> > spent some time having a look on my Win 10 machine (which I don't
> >> > usually use for development), but so far can't replicate.
> >> >
> >> > However ...
> >> >
> >> > On Fri, 14 May 2021 at 23:45, Scott Palmer 
> wrote:
> >> >> My netbeans.conf file contains
> >> >> ...
> >> >> -J-Dorg.netbeans.core.NbClipboard=-1
> >> >
> >> > I think that should be -J-Dorg.netbeans.NbClipboard.level=FINEST
> >> >
> >> > With that I do get a lot of output from the clipboard in the log.
> >> > Hopefully the logging if / when it fails may tell us something.
> >> >
> >> > Incidentally, your other log output about System clipboard not
> >> > available is I think because the Windows clipboard can only be opened
> >> > by one application at a time.  Not sure if it's related or not.
> >> >
> >> > Best wishes,
> >> >
> >> > Neil
> >>
> >>
> >> -
> >> 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: [VOTE] Release Apache NetBeans 13 macOS installer

[Scott Palmer]

application, doesn't that make it
>> important enough to include support in the installer?
>> The blame may be on sdkman but, as a user I have not yet suffered because
>> of it, it's only when I try to install Netbeans that I run into an issue.
>> If that's true for a significant volume of other users then I suspect
>> people will believe the blame lies with Netbeans, regardless of what might
>> be the truth.
>> I'm happy to install a java version outside of sdkman in order to install
>> Netbeans. I can even remove it after Netbeans is installed, which again
>> points to only the installer needing Java to be in
>> /Library/Java/JavaVirtualMachines. For others it might be enough for them
>> to just give up on Netbeans and not bother, which would be a shame for
>> Netbeans to lose (potential) users that way.
>> I realise the answer may be "We're happy to take your contribution to the
>> installer to add support for sdkman", and I understand why that is the
>> case. I will certainly take a look at the installer to see if there's even
>> a chance I could contribute something even though native macos development
>> is not my forte but, I hope that sdkman support could be considered outside
>> of what I may or may not be able to contribute.
>> I'm a very happy user of Netbeans and it's clear to see Netbeans get better
>> each and every version. I'd like to say a huge thank you to the team for
>> the great work.
>> Cheers
>>> On Tue, 22 Mar 2022 at 20:49, Scott Palmer  wrote:
>>> JDKs installed by SDKMAN don’t work with /usr/libexec/java_home.  That’s
>>> why I believe SDKMAN should not be used for Java on macOS, it doesn’t
>>> integrate properly. (I brought this up to SDKMAN team and they don’t want
>>> to write any files outside of their controlled space.  I get it, but the
>>> user suffers as a result.)
>>> 
>>> You might be able to work around it by sym-linking the SDKMAN installed
>>> JDK into the correct location at /Libraries/Java/JavaVirtualMachines - but
>>> if you have to manage it yourself, what is SDKMAN doing for you?
>>> 
>>> Scott
>>> 
>>>> On Mar 22, 2022, at 1:15 PM, John Mc  wrote:
>>>> 
>>>> +1 (binding)
>>>> 
>>>> Vote Closed, I will tally up the votes later and move the artefacts over.
>>>> 
>>>> @Djamel TORCHE   Sorry just seeing this now.
>>> What
>>>> output do you get when you run this in your terminal
>>> "/usr/libexec/java_home"
>>>> That's how the installer verifies Java exists.
>>>> 
>>>> Maybe for NB14 I might do an RC for the macOS installer to help verify no
>>>> late issues in future.
>>>> 
>>>> John
>>>> 
>>>>> On Tue, 22 Mar 2022 at 14:12, Neil C Smith 
>>> wrote:
>>>>> 
>>>>> +1 (binding)
>>>>> 
>>>>> Checksum and signature checked.
>>>>> Installed and ran successfully.
>>>>> Checked module versions match git hash.
>>>>> 
>>>>> JDK 17 Temurin x86_64 running on M1 macOS 12.2.1
>>>>> 
>>>>> Thanks John!!!
>>>>> 
>>>>> Best wishes,
>>>>> 
>>>>> Neil
>>>>> 
>>>>>> On Sat, 19 Mar 2022 at 10:11, John Mc 
>>> wrote:
>>>>>> 
>>>>>> This has been a lot longer than I wanted as I got caught up with work,
>>>>> but
>>>>>> here is the updated macOS installer for Apache NetBeans 13.
>>>>>> 
>>>>>> Primary voting artefact :
>>>>>> 
>>>>> 
>>> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-installers/13/Apache-NetBeans-13-bin-macosx.dmg
>>>>>> 
>>>>>> SHA512 checksum :
>>>>>> 
>>>>> 
>>> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-installers/13/Apache-NetBeans-13-bin-macosx.dmg.sha512
>>>>>> 
>>>>>> 
>>>>> 
>>> 68cd93b697b8fa02013d4ab69f773a93c3c42f92498578470af6d808179d292649b85bdb946a9bc75d9cc94aba3d4c8e0d0a3eb3fee565ab390810ad7b609b49
>>>>>> Apache-NetBeans-13-bin-macosx.dmg
>>>>>> 
>>>>>> KEYS file :
>>>>>> https://dist.apache.org/repos/dist/release/netbeans/KEYS
>>>>>> 
>>>>>> PGP signature file :
>>>>>> 
>>>>> 
>>> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-installers/13/Apache-NetBeans-13-bin-macosx.dmg.asc
>>>>>> 
>>>>>> Built locally using the artefacts found in the Jenkins job:
>>>>>> 
>>>>> 
>>> https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/netbeans/job/release130/20/
>>>>>> 
>>>>>> NOTE: The distpreparation artefact from this Jenkins job was replaced
>>>>> with:
>>>>>> 
>>>>> 
>>> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-installers/13/distpreparation.zip
>>>>>> The changes can be compared against the PR:
>>>>>> https://github.com/apache/netbeans/pull/3699
>>>>>> 
>>>>>> This vote is going to be open at least 72 hours, vote with +1, 0, and
>>>>>> -1 as usual. Please mark your vote with (binding) if you're an Apache
>>>>>> NetBeans PMC member.
>>>>>> 
>>>>>> This vote is dependent on the main Apache NetBeans 13 release vote
>>>>> passing.
>>>>>> 
>>>>>> Regards
>>>>>> 
>>>>>> John
> 

Re: [VOTE] Release Apache NetBeans 13 macOS installer

[Scott Palmer]

“The blame may be on sdkman but, as a user I have not yet suffered because
of it, it's only when I try to install Netbeans that I run into an issue.”

So you *have* suffered because of it. 

It makes sense to support JDKs installed with SDKMAN. It should be simple 
enough. It probably would be mostly shell scripts, I doubt it would need native 
macOS programming. (Someone correct me if I’m wrong here.) If it was too much 
effort, I doubt the user base is significant specifically for installing the 
JDK on macOS.  I just don’t recommend SDKMAN for installing JDKs on macOS 
because of its poor integration. For other SDKs it is probably not as bad. 

Scott

> On Mar 24, 2022, at 2:23 PM, Alex Lewis  wrote:
> 
> Hi,
> 
> Just to offer an opinion of an average netbeans user regarding Netbeans and
> sdkman... As of Netbeans 12.1, sdkman is explicitly supported for detecting
> available JVMs. In my opinion it is an odd inconsistency for the main
> application to support sdkman but not the installer. Besides that and as
> far as I know, sdkman is a widely used tool for managing Java versions on
> macos, even with its avoidance of java_home. In which case, not supporting
> it in the installer impacts some amount of a large user base. By
> not supporting sdkman in the installer it means an additional complication
> at the very first step in using Netbeans and that to me feels unfortunate.
> If sdkman was an esoteric tool used by a small minority then I could
> understand any reluctance to put in the effort but, I have the impression
> that sdkman's user base would be large enough to warrant the effort. I
> obviously can't quantify that and I may be totally wrong about
> its popularity, if I am then I apologise. I just think that if it was
> important enough to include in the main application, doesn't that make it
> important enough to include support in the installer?
> 
> The blame may be on sdkman but, as a user I have not yet suffered because
> of it, it's only when I try to install Netbeans that I run into an issue.
> If that's true for a significant volume of other users then I suspect
> people will believe the blame lies with Netbeans, regardless of what might
> be the truth.
> 
> I'm happy to install a java version outside of sdkman in order to install
> Netbeans. I can even remove it after Netbeans is installed, which again
> points to only the installer needing Java to be in
> /Library/Java/JavaVirtualMachines. For others it might be enough for them
> to just give up on Netbeans and not bother, which would be a shame for
> Netbeans to lose (potential) users that way.
> 
> I realise the answer may be "We're happy to take your contribution to the
> installer to add support for sdkman", and I understand why that is the
> case. I will certainly take a look at the installer to see if there's even
> a chance I could contribute something even though native macos development
> is not my forte but, I hope that sdkman support could be considered outside
> of what I may or may not be able to contribute.
> 
> I'm a very happy user of Netbeans and it's clear to see Netbeans get better
> each and every version. I'd like to say a huge thank you to the team for
> the great work.
> 
> Cheers
> 
> 
> 
>> On Tue, 22 Mar 2022 at 20:49, Scott Palmer  wrote:
>> 
>> JDKs installed by SDKMAN don’t work with /usr/libexec/java_home.  That’s
>> why I believe SDKMAN should not be used for Java on macOS, it doesn’t
>> integrate properly. (I brought this up to SDKMAN team and they don’t want
>> to write any files outside of their controlled space.  I get it, but the
>> user suffers as a result.)
>> 
>> You might be able to work around it by sym-linking the SDKMAN installed
>> JDK into the correct location at /Libraries/Java/JavaVirtualMachines - but
>> if you have to manage it yourself, what is SDKMAN doing for you?
>> 
>> Scott
>> 
>>>> On Mar 22, 2022, at 1:15 PM, John Mc  wrote:
>>> 
>>> +1 (binding)
>>> 
>>> Vote Closed, I will tally up the votes later and move the artefacts over.
>>> 
>>> @Djamel TORCHE   Sorry just seeing this now.
>> What
>>> output do you get when you run this in your terminal
>> "/usr/libexec/java_home"
>>> That's how the installer verifies Java exists.
>>> 
>>> Maybe for NB14 I might do an RC for the macOS installer to help verify no
>>> late issues in future.
>>> 
>>> John
>>> 
>>>> On Tue, 22 Mar 2022 at 14:12, Neil C Smith 
>> wrote:
>>>> 
>>>> +1 (binding)
>>>> 
>>>> Checksum and signature checked.
>>>> Installed and ran successful

Re: [VOTE] Release Apache NetBeans 13 macOS installer

[Scott Palmer]

JDKs installed by SDKMAN don’t work with /usr/libexec/java_home.  That’s why I 
believe SDKMAN should not be used for Java on macOS, it doesn’t integrate 
properly. (I brought this up to SDKMAN team and they don’t want to write any 
files outside of their controlled space.  I get it, but the user suffers as a 
result.)

You might be able to work around it by sym-linking the SDKMAN installed JDK 
into the correct location at /Libraries/Java/JavaVirtualMachines - but if you 
have to manage it yourself, what is SDKMAN doing for you?

Scott

> On Mar 22, 2022, at 1:15 PM, John Mc  wrote:
> 
> +1 (binding)
> 
> Vote Closed, I will tally up the votes later and move the artefacts over.
> 
> @Djamel TORCHE   Sorry just seeing this now.  What
> output do you get when you run this in your terminal "/usr/libexec/java_home"
> That's how the installer verifies Java exists.
> 
> Maybe for NB14 I might do an RC for the macOS installer to help verify no
> late issues in future.
> 
> John
> 
>> On Tue, 22 Mar 2022 at 14:12, Neil C Smith  wrote:
>> 
>> +1 (binding)
>> 
>> Checksum and signature checked.
>> Installed and ran successfully.
>> Checked module versions match git hash.
>> 
>> JDK 17 Temurin x86_64 running on M1 macOS 12.2.1
>> 
>> Thanks John!!!
>> 
>> Best wishes,
>> 
>> Neil
>> 
>>> On Sat, 19 Mar 2022 at 10:11, John Mc  wrote:
>>> 
>>> This has been a lot longer than I wanted as I got caught up with work,
>> but
>>> here is the updated macOS installer for Apache NetBeans 13.
>>> 
>>> Primary voting artefact :
>>> 
>> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-installers/13/Apache-NetBeans-13-bin-macosx.dmg
>>> 
>>> SHA512 checksum :
>>> 
>> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-installers/13/Apache-NetBeans-13-bin-macosx.dmg.sha512
>>> 
>>> 
>> 68cd93b697b8fa02013d4ab69f773a93c3c42f92498578470af6d808179d292649b85bdb946a9bc75d9cc94aba3d4c8e0d0a3eb3fee565ab390810ad7b609b49
>>> Apache-NetBeans-13-bin-macosx.dmg
>>> 
>>> KEYS file :
>>> https://dist.apache.org/repos/dist/release/netbeans/KEYS
>>> 
>>> PGP signature file :
>>> 
>> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-installers/13/Apache-NetBeans-13-bin-macosx.dmg.asc
>>> 
>>> Built locally using the artefacts found in the Jenkins job:
>>> 
>> https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/netbeans/job/release130/20/
>>> 
>>> NOTE: The distpreparation artefact from this Jenkins job was replaced
>> with:
>>> 
>> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-installers/13/distpreparation.zip
>>> The changes can be compared against the PR:
>>> https://github.com/apache/netbeans/pull/3699
>>> 
>>> This vote is going to be open at least 72 hours, vote with +1, 0, and
>>> -1 as usual. Please mark your vote with (binding) if you're an Apache
>>> NetBeans PMC member.
>>> 
>>> This vote is dependent on the main Apache NetBeans 13 release vote
>> passing.
>>> 
>>> Regards
>>> 
>>> John
>> 
>> -
>> 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: [VOTE] Release Apache NetBeans 13 macOS installer

[Scott Palmer]

+1

I purposely left my old NB 13 install (from previous macOS installer) in place. 
 The installer *should* work, or at least fail with a reasonable message as to 
why it could not proceed.  It failed for me too.  The error says “The 
installation failed. The Installer encountered an error that caused the 
installation to fail. Contact the software manufacturer for assistance.”  It 
does appear that this happens in or right after the phase that says “Validating 
Packages”.

Failing for reasons unknown is obviously a very bad user experience.  *IF* it 
can be reasonably prevented, it should be.  That said… the situation is likely 
only going to come up for those that were experimenting with earlier builds, 
not the vast majority, so I’m also giving it a +1.

It seems the old installer used a different folder hierarchy, with an extra 
folder (at least that’s what I had on my system).

OLD:
/Applications/NetBeans/Apache NetBeans 13/Apache NetBeans 13.app

NEW:
/Applications/NetBeans/Apache NetBeans 13.app

After moving the old "Apache NetBeans 13” folder to the trash, the install 
succeeded.


Scott


> On Mar 20, 2022, at 11:13 AM, Peter Ream  wrote:
> 
> +1
> 
> I’m changing my -1 vote to +1. I had remnants of a previous NB13 install 
> remaining. After deleting all NB13 remnants, it installed fine. SHA512 
> matched. Ran several projects, all good. Installed a second time to be sure.
> 
> MacBook Air M1, Monterey 12.3 (this was a change from earlier), Azul 17.
> 
> Sorry for my mistake.
> 
> On 2022/03/19 14:43:27 Peter Ream wrote:
>> -1
>> 
>> The sha512 matched. I get error I get error “Validating Packages…” An error 
>> occurred while running scripts. I’ve attached install.log.
>> MacBook Air M1, Monterey 12.2.1.
>> 
>> 
> -
> 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: master is now buildable on JDK 17

[Scott Palmer]

Nice!  I just did a build on macOS with JDK 17.0.2:

ant -Dcluster.config=full   
…
BUILD SUCCESSFUL
Total time: 9 minutes 54 seconds

Yay!

Next step, move the build to Gradle ;-)

Cheers,

Scott


> On Mar 12, 2022, at 8:13 PM, Michael Bien  wrote:
> 
> with all clusters, as seen here:
> 
> https://github.com/apache/netbeans/runs/5524901974
> 
> best regards,
> 
> michael

-
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: Release NetBeans 13 without macOS installer (for now)?

[Scott Palmer]

No.  That’s with the latest and greatest release: macOS Monterey 12.2.1

If you just double-click the .pkg you get the message: “Apache NetBeans 13.pkg” 
can’t be opened because Apple cannot check it for malicious software.

...and there is only an “OK” button to dismiss the dialog.

But if you right-click and hold Option while selecting Open, the same message 
appears but now there are two buttons on the dialog, “Open” and “Cancel”.

Scott


> On Mar 10, 2022, at 8:49 PM, Steve Hannah  wrote:
> 
> Are you on an older system?  I didn't think you could do that anymore after
> catalina.
> 
> On Thu, Mar 10, 2022 at 5:47 PM Scott Palmer  wrote:
> 
>> For the record. I used the macOS installer and did an Option-right-click
>> -> Open so I could override the security warnings and proceed with the
>> install.  Obviously not what we want, but the result was a working NB13.
>> 
>> Scott
>> 
>>> On Mar 10, 2022, at 6:32 PM, Steve Hannah  wrote:
>>> 
>>> I'd like to take a stab at building a MacOS installer using jDeploy.
>> I'm
>>> having trouble getting the binary ZIP version running on my Mac though.
>>> I downloaded this:
>>> 
>> https://www.apache.org/dyn/closer.cgi/netbeans/netbeans/13/netbeans-13-bin.zip
>>> 
>>> I unzip and run it and this is the output I get.
>>> 
>>> 
>>> Steves-Mac-Pro:netbeans shannah$ ./bin/netbeans
>>> 
>>> Unknown option: n
>>> 
>>> Usage: head [-options] ...
>>> 
>>>   -muse method for the request (default is 'HEAD')
>>> 
>>>   -fmake request even if head believes method is illegal
>>> 
>>>   -b  Use the specified URL as base
>>> 
>>>   -t   Set timeout value
>>> 
>>>   -i  Set the If-Modified-Since header on the request
>>> 
>>>   -c  use this content-type for POST, PUT, CHECKIN
>>> 
>>>   -aUse text mode for content I/O
>>> 
>>>   -p  use this as a proxy
>>> 
>>>   -Pdon't load proxy settings from environment
>>> 
>>>   -Hsend this HTTP header (you can specify several)
>>> 
>>> 
>>>   -uDisplay method and URL before any response
>>> 
>>>   -UDisplay request headers (implies -u)
>>> 
>>>   -sDisplay response status code
>>> 
>>>   -SDisplay response status chain
>>> 
>>>   -eDisplay response headers
>>> 
>>>   -dDo not display content
>>> 
>>>   -oProcess HTML content in various ways
>>> 
>>> 
>>>   -vShow program version
>>> 
>>>   -hPrint this message
>>> 
>>> 
>>>   -xExtra debugging output
>>> 
>>> /bin/bash: : No such file or directory
>>> 
>>> 
>>> 
>>> Mac OS Majave 10.14.6
>>> 
>>> 
>>> I must be missing something obvious.  Can anyone spot my mistake?
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> On Fri, Mar 4, 2022 at 3:36 PM John Mc 
>> wrote:
>>>> 
>>>> I don't think John knows why the installer is failing Apple's
>>>> notarization process right now for sure.  Although there's a whole
>>>> bunch of reasons NetBeans probably shouldn't pass if Apple's
>>>> guidelines are read strictly.  Fixing it might require code changes.
>>>> 
>>>> Yeah so as I understand it right now, up to now, we got away with it, as
>>>> Apache NetBeans was being notarized but shouldn't have been, and
>>>> potentially now gatekeeper is cleverer than the notarization service...
>>>> 
>>>> I'm not signing the .app, but the current issue is that I think we need
>> to
>>>> loop through jars, and sign any embedded native libraries(.
>>>> dylib|.jnilib|.so|bin), as these are not being reported as errors as
>> they
>>>> are not signed.  Very similar to this post[1].
>>>> 
>>>> I've created 2 PRs for my current changes(one in netbeans, the other in
>> the
>>>> jenkins-lib project) to get me where I am at the moment.  I'll take a
>> look
>>>> tomorrow and see what makes sense in terms of signing the embedded
>> native
>>>> libraries...
>>>> 
>>>> [1]: https://stackoverflow.com/a/53528020/612072
>>>> 
>>>> John
>

Re: Release NetBeans 13 without macOS installer (for now)?

[Scott Palmer]

For the record. I used the macOS installer and did an Option-right-click -> 
Open so I could override the security warnings and proceed with the install.  
Obviously not what we want, but the result was a working NB13.

Scott

> On Mar 10, 2022, at 6:32 PM, Steve Hannah  wrote:
> 
> I'd like to take a stab at building a MacOS installer using jDeploy.  I'm
> having trouble getting the binary ZIP version running on my Mac though.
> I downloaded this:
> https://www.apache.org/dyn/closer.cgi/netbeans/netbeans/13/netbeans-13-bin.zip
> 
> I unzip and run it and this is the output I get.
> 
> 
> Steves-Mac-Pro:netbeans shannah$ ./bin/netbeans
> 
> Unknown option: n
> 
> Usage: head [-options] ...
> 
>-muse method for the request (default is 'HEAD')
> 
>-fmake request even if head believes method is illegal
> 
>-b  Use the specified URL as base
> 
>-t   Set timeout value
> 
>-i  Set the If-Modified-Since header on the request
> 
>-c  use this content-type for POST, PUT, CHECKIN
> 
>-aUse text mode for content I/O
> 
>-p  use this as a proxy
> 
>-Pdon't load proxy settings from environment
> 
>-Hsend this HTTP header (you can specify several)
> 
> 
>-uDisplay method and URL before any response
> 
>-UDisplay request headers (implies -u)
> 
>-sDisplay response status code
> 
>-SDisplay response status chain
> 
>-eDisplay response headers
> 
>-dDo not display content
> 
>-oProcess HTML content in various ways
> 
> 
>-vShow program version
> 
>-hPrint this message
> 
> 
>-xExtra debugging output
> 
> /bin/bash: : No such file or directory
> 
> 
> 
> Mac OS Majave 10.14.6
> 
> 
> I must be missing something obvious.  Can anyone spot my mistake?
> 
> 
> 
> 
> 
>> On Fri, Mar 4, 2022 at 3:36 PM John Mc  wrote:
>> 
>> I don't think John knows why the installer is failing Apple's
>> notarization process right now for sure.  Although there's a whole
>> bunch of reasons NetBeans probably shouldn't pass if Apple's
>> guidelines are read strictly.  Fixing it might require code changes.
>> 
>> Yeah so as I understand it right now, up to now, we got away with it, as
>> Apache NetBeans was being notarized but shouldn't have been, and
>> potentially now gatekeeper is cleverer than the notarization service...
>> 
>> I'm not signing the .app, but the current issue is that I think we need to
>> loop through jars, and sign any embedded native libraries(.
>> dylib|.jnilib|.so|bin), as these are not being reported as errors as they
>> are not signed.  Very similar to this post[1].
>> 
>> I've created 2 PRs for my current changes(one in netbeans, the other in the
>> jenkins-lib project) to get me where I am at the moment.  I'll take a look
>> tomorrow and see what makes sense in terms of signing the embedded native
>> libraries...
>> 
>> [1]: https://stackoverflow.com/a/53528020/612072
>> 
>> John
>> 
>>> On Fri, 4 Mar 2022 at 12:54, Neil C Smith  wrote:
>>> 
>>> On Fri, 4 Mar 2022 at 12:35, antonio  wrote:
 I don't see a reason "to roll a new source release to fix whatever the
 issue now is" with the macOS installer.
 
 I think it's ok to wait for the NB _14_ macOS installer vote.
>>> 
>>> Well, not having a macOS NB 13 installer at all is also an option, I
>> guess!
>>> 
>>> I don't think John knows why the installer is failing Apple's
>>> notarization process right now for sure.  Although there's a whole
>>> bunch of reasons NetBeans probably shouldn't pass if Apple's
>>> guidelines are read strictly.  Fixing it might require code changes.
>>> Hopefully not.
>>> 
 Maybe more
 people with macOS is interested in voting by then.
>>> 
>>> I don't think there's a shortage of people to vote.
>>> 
>>> Best wishes,
>>> 
>>> Neil
>>> 
>>> -
>>> 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
>>> 
>>> 
>>> 
>>> 
>> 
> 
> 
> -- 
> Steve Hannah
> Web Lite Solutions Corp.

-
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: Build Instructions for NetBeans - README incomplete

[Scott Palmer]

> On Feb 15, 2022, at 6:55 AM, Neil C Smith  wrote:
> 
> On Mon, 14 Feb 2022 at 22:13, Scott Palmer  wrote:
>> [releasejson] Taking release info from json
>> [releasejson] Processing release: [release1243, release90, master, 
>> release110, release121, release120, release112, release123, release100, 
>> release111, release122, release125, release113, release124]
>> 
>> BUILD FAILED
>> /Users/scott/dev/opensource/netbeans/nbbuild/build.xml:134: Cannot retrieve 
>> key publish_apidoc, this is forShould we publish this Apidoc
> 
> You have very old cached release information there!
> 
> Assuming git checkout, try git clean -dxf
> 
> Neil


Thanks, that seems to have done it.

The build now works for the ‘basic’ cluster.

I also tried to do the ‘full' build with JDK 17 but it fails in the j2ee 
module.  Apparently this isn’t unexpected. I didn’t realize the changes between 
JDK 11 and 17 were enough to break things like that. 

The j2ee build issues I saw are all about not being able to access or find some 
symbols.  It looks like some generated code is not getting generated properly.

-do-compile:
 [nb-javac] Compiling 160 source files to 
/Users/scott/dev/opensource/netbeans/enterprise/j2eeserver/build/classes
 [nb-javac] Ignoring source, target and bootclasspath as release has been set
   [repeat] 
/Users/scott/dev/opensource/netbeans/enterprise/j2eeserver/src/org/netbeans/modules/j2ee/deployment/impl/Server.java:48:
 error: cannot access NetbeansDeployment
   [repeat] import 
org.netbeans.modules.j2ee.deployment.impl.gen.nbd.NetbeansDeployment;
   [repeat] ^
   [repeat]   bad source file: 
/Users/scott/dev/opensource/netbeans/enterprise/j2eeserver/build/classes-generated/org/netbeans/modules/j2ee/deployment/impl/gen/nbd/NetbeansDeployment.java
   [repeat] file does not contain class 
org.netbeans.modules.j2ee.deployment.impl.gen.nbd.NetbeansDeployment
   [repeat] Please remove or make sure it appears in the correct 
subdirectory of the sourcepath.

^^ This “bad source file” file exists, but it is empty.

   [repeat] 
/Users/scott/dev/opensource/netbeans/enterprise/j2eeserver/src/org/netbeans/modules/j2ee/deployment/devmodules/api/J2eeModule.java:25:
 warning: [deprecation] J2eeModuleImplementation in 
org.netbeans.modules.j2ee.deployment.devmodules.spi has been deprecated
   [repeat] import 
org.netbeans.modules.j2ee.deployment.devmodules.spi.J2eeModuleImplementation;
   [repeat]   ^
   [repeat] 
/Users/scott/dev/opensource/netbeans/enterprise/j2eeserver/src/org/netbeans/modules/j2ee/deployment/impl/Server.java:47:
 error: cannot find symbol
   [repeat] import org.netbeans.modules.j2ee.deployment.impl.gen.nbd.ConfigBean;
   [repeat] ^
   [repeat]   symbol:   class ConfigBean
   [repeat]   location: package 
org.netbeans.modules.j2ee.deployment.impl.gen.nbd
   [repeat] 
/Users/scott/dev/opensource/netbeans/enterprise/j2eeserver/src/org/netbeans/modules/j2ee/deployment/impl/Server.java:49:
 error: cannot find symbol
   [repeat] import 
org.netbeans.modules.j2ee.deployment.impl.gen.nbd.WebContextRoot;
   [repeat] ^


Regards,

Scott

Re: Build Instructions for NetBeans - README incomplete

[Scott Palmer]

ant build-nozip -Dcluster.config=basic

gives the same error.


> On Feb 14, 2022, at 5:43 PM, Michael Bien  wrote:
> 
> ah ok :)
> 
> only the "basic" cluster builds on jdk 17 last time i checked 
> (https://github.com/apache/netbeans/pull/3278).
> 
> ant build-nozip -Dcluster.config=basic
> 
> -mbien
> 
> On 14.02.22 23:40, Scott Palmer wrote:
>> That’s the thread that inspired me to give it a go ;-)
>> 
>> For the record, I'm using JDK 17.0.2 on macOS 12.2.1 with Ant 1.10.12
>> 
>> Scott
>> 
>>> On Feb 14, 2022, at 5:34 PM, Michael Bien  wrote:
>>> 
>>> ok, don't know what that is then.
>>> 
>>> check the thread from 2h ago. I built a fresh checkout on JDK 11 and it 
>>> worked.
>>> 
>>> -mbien
>>> 
>>> On 14.02.22 23:31, Scott Palmer wrote:
>>>> Same error.  "Cannot retrieve key publish_apidoc, this is forShould we 
>>>> publish this Apidoc”
>>>> 
>>>> Yes I’m connected to the internet, no local changes, up-to-date with 
>>>> master.
>>>> 
>>>> Scott
>>>> 
>>>> 
>>>>> On Feb 14, 2022, at 5:14 PM, Michael Bien  wrote:
>>>>> 
>>>>> try
>>>>> ant build-nozip
>>>>> 
>>>>> -mbien
>>>>> 
>>>>> 
>>>>> On 14.02.22 23:13, Scott Palmer wrote:
>>>>>> As per the README I tried:
>>>>>> 
>>>>>> $ ant -Dcluster.config=full
>>>>>> 
>>>>>> This resulted in:
>>>>>> 
>>>>>> Buildfile: /Users/scott/dev/opensource/netbeans/build.xml
>>>>>> 
>>>>>> -jdk-pre-preinit:
>>>>>> 
>>>>>> -jdk-preinit:
>>>>>> 
>>>>>> -jdk-warn:
>>>>>> 
>>>>>> -jdk-presetdef-basic:
>>>>>> 
>>>>>> -jdk-default:
>>>>>> 
>>>>>> -jdk-init:
>>>>>> 
>>>>>> -load-build-properties:
>>>>>> 
>>>>>> bootstrap:
>>>>>> [javac] Compiling 1 source file to 
>>>>>> /Users/scott/dev/opensource/netbeans/nbbuild/build/antclasses
>>>>>> [javac] warning: [options] bootstrap class path not set in 
>>>>>> conjunction with -source 8
>>>>>> [javac] 1 warning
>>>>>> [downloadbinaries] Creating 
>>>>>> /Users/scott/dev/opensource/netbeans/nbbuild/external/apache-rat-0.12.jar
>>>>>> [downloadbinaries] Creating 
>>>>>> /Users/scott/dev/opensource/netbeans/nbbuild/external/codesnippet-doclet-0.30.jar
>>>>>> [downloadbinaries] Creating 
>>>>>> /Users/scott/dev/opensource/netbeans/nbbuild/external/sigtest-maven-plugin-1.4.jar
>>>>>> [downloadbinaries] Creating 
>>>>>> /Users/scott/dev/opensource/netbeans/nbbuild/external/json-simple-1.1.1.jar
>>>>>> [downloadbinaries] Creating 
>>>>>> /Users/scott/dev/opensource/netbeans/nbbuild/external/tool-12.3.jar
>>>>>> [downloadbinaries] Creating 
>>>>>> /Users/scott/dev/opensource/netbeans/platform/javahelp/external/jhall-2.0_05.jar
>>>>>> [downloadbinaries] Creating 
>>>>>> /Users/scott/dev/opensource/netbeans/platform/libs.junit4/external/junit-4.13.2.jar
>>>>>> [downloadbinaries] Creating 
>>>>>> /Users/scott/dev/opensource/netbeans/platform/libs.junit4/external/hamcrest-core-1.3.jar
>>>>>>  [echo] Bootstrapping NetBeans-specific Ant extensions...
>>>>>> [javac] Compiling 6 source files to 
>>>>>> /Users/scott/dev/opensource/netbeans/nbbuild/build/antclasses
>>>>>> [javac] warning: [options] bootstrap class path not set in 
>>>>>> conjunction with -source 8
>>>>>> [javac] 1 warning
>>>>>>   [jar] Building jar: 
>>>>>> /Users/scott/dev/opensource/netbeans/nbbuild/build/nbantext.jar
>>>>>> 
>>>>>> getjsonfile:
>>>>>>  [copy] Warning: Could not find file 
>>>>>> /Users/scott/dev/opensource/netbeans/nbbuild/netbeansrelease.json to 
>>>>>> copy.
>>>>>>  [copy] Warning: Could not find file 
>>>>>> /Users/scott/dev/opensource/netbeans

Re: Build Instructions for NetBeans - README incomplete

[Scott Palmer]

That’s the thread that inspired me to give it a go ;-)

For the record, I'm using JDK 17.0.2 on macOS 12.2.1 with Ant 1.10.12

Scott

> On Feb 14, 2022, at 5:34 PM, Michael Bien  wrote:
> 
> ok, don't know what that is then.
> 
> check the thread from 2h ago. I built a fresh checkout on JDK 11 and it 
> worked.
> 
> -mbien
> 
> On 14.02.22 23:31, Scott Palmer wrote:
>> Same error.  "Cannot retrieve key publish_apidoc, this is forShould we 
>> publish this Apidoc”
>> 
>> Yes I’m connected to the internet, no local changes, up-to-date with master.
>> 
>> Scott
>> 
>> 
>>> On Feb 14, 2022, at 5:14 PM, Michael Bien  wrote:
>>> 
>>> try
>>> ant build-nozip
>>> 
>>> -mbien
>>> 
>>> 
>>> On 14.02.22 23:13, Scott Palmer wrote:
>>>> As per the README I tried:
>>>> 
>>>> $ ant -Dcluster.config=full
>>>> 
>>>> This resulted in:
>>>> 
>>>> Buildfile: /Users/scott/dev/opensource/netbeans/build.xml
>>>> 
>>>> -jdk-pre-preinit:
>>>> 
>>>> -jdk-preinit:
>>>> 
>>>> -jdk-warn:
>>>> 
>>>> -jdk-presetdef-basic:
>>>> 
>>>> -jdk-default:
>>>> 
>>>> -jdk-init:
>>>> 
>>>> -load-build-properties:
>>>> 
>>>> bootstrap:
>>>> [javac] Compiling 1 source file to 
>>>> /Users/scott/dev/opensource/netbeans/nbbuild/build/antclasses
>>>> [javac] warning: [options] bootstrap class path not set in conjunction 
>>>> with -source 8
>>>> [javac] 1 warning
>>>> [downloadbinaries] Creating 
>>>> /Users/scott/dev/opensource/netbeans/nbbuild/external/apache-rat-0.12.jar
>>>> [downloadbinaries] Creating 
>>>> /Users/scott/dev/opensource/netbeans/nbbuild/external/codesnippet-doclet-0.30.jar
>>>> [downloadbinaries] Creating 
>>>> /Users/scott/dev/opensource/netbeans/nbbuild/external/sigtest-maven-plugin-1.4.jar
>>>> [downloadbinaries] Creating 
>>>> /Users/scott/dev/opensource/netbeans/nbbuild/external/json-simple-1.1.1.jar
>>>> [downloadbinaries] Creating 
>>>> /Users/scott/dev/opensource/netbeans/nbbuild/external/tool-12.3.jar
>>>> [downloadbinaries] Creating 
>>>> /Users/scott/dev/opensource/netbeans/platform/javahelp/external/jhall-2.0_05.jar
>>>> [downloadbinaries] Creating 
>>>> /Users/scott/dev/opensource/netbeans/platform/libs.junit4/external/junit-4.13.2.jar
>>>> [downloadbinaries] Creating 
>>>> /Users/scott/dev/opensource/netbeans/platform/libs.junit4/external/hamcrest-core-1.3.jar
>>>>  [echo] Bootstrapping NetBeans-specific Ant extensions...
>>>> [javac] Compiling 6 source files to 
>>>> /Users/scott/dev/opensource/netbeans/nbbuild/build/antclasses
>>>> [javac] warning: [options] bootstrap class path not set in conjunction 
>>>> with -source 8
>>>> [javac] 1 warning
>>>>   [jar] Building jar: 
>>>> /Users/scott/dev/opensource/netbeans/nbbuild/build/nbantext.jar
>>>> 
>>>> getjsonfile:
>>>>  [copy] Warning: Could not find file 
>>>> /Users/scott/dev/opensource/netbeans/nbbuild/netbeansrelease.json to copy.
>>>>  [copy] Warning: Could not find file 
>>>> /Users/scott/dev/opensource/netbeans/nbbuild/gitinfo.properties to copy.
>>>> 
>>>> -gitinfo.ispresent:
>>>> 
>>>> -git.up:
>>>>  [echo] Processing build with branch master and hash 
>>>> 0dfe95f624fa6f054441f324d698a6d499d52544
>>>> 
>>>> -git.down:
>>>> 
>>>> getgitinformation:
>>>>  [echo] Building branch: ${metabuild.branch}
>>>> [releasejson] Taking release info from json
>>>> [releasejson] Processing release: [release1243, release90, master, 
>>>> release110, release121, release120, release112, release123, release100, 
>>>> release111, release122, release125, release113, release124]
>>>> 
>>>> BUILD FAILED
>>>> /Users/scott/dev/opensource/netbeans/nbbuild/build.xml:134: Cannot 
>>>> retrieve key publish_apidoc, this is forShould we publish this Apidoc
>>>> 
>>>> Total time: 2 seconds
>>>> ———
>>>> 
>>>> Seems there is more to it.  "Cannot retrieve key publish_apidoc, this is 
>>>> forShould we publish this Apidoc” seems to indicate it wants to publish 
>>>> something to a server that needs an encryption key or something?
>>>> 
>>>> What’s the process for someone that just wants to build locally?  The 
>>>> README didn’t seem to point to any other instructions.
>>>> 
>>>> I tried just plain “ant” and got the same result.  So the instructions 
>>>> here 
>>>> https://netbeans.apache.org/participate/submit-pr.html#contributing-code 
>>>> don’t seem to be working either.
>>>> 
>>>> 
>>>> 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