Re: Do we need JUnit 5 support for Java 11 based modules

[László Kishalmi]

Here is the bad boy:
https://github.com/apache/netbeans/pull/6178

On Tue, Jul 11, 2023 at 4:47 AM Michael Bien  wrote:

> Hi Laszlo,
>
>
> On 11.07.23 08:33, Laszlo Kishalmi wrote:
> > Dear all,
> >
> >
> > I was just trying some Java 11 stuff on the HCL support. The majority
> > of the test are fine, but a few fails wit NoClassDefFound exception.
> > AFAIK, that could be related to a JUnit 4 and Java 9+ issue.
>
> I am not sure if this is a junit 4 issue - might be something else.
>
> What test is it? I could take a look.
>
> we have many tests which do already run on JDK 11 in CI which makes me
> think that the junit version is probably not the root cause for this.
>
> -mbien
>
> >
> > I must confess, that my JUnit-Fu is very limited especially beyond
> > JUnit 4.
> >
> > So the question is: what can/shall I do now?
> >
> >
> > --
> >
> >   Laszlo Kishalmi
> >
> >
> > -
> > 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 + ssh -x

[László Kishalmi]

Better to use nomachine remote desktop...

On Thu, May 4, 2023, 23:53 Peter Kovacs  wrote:

>
> Am 05.05.23 um 08:05 schrieb Antonio:
> > Hi Peter,
> >
> > I'm afraid this email of yours has too little information and is not
> > understandable.
> >
> > The "ssh -x" part in the subject suggests you're doing some sort of
> > X11 forwarding for this remote server, but that would require a
> > capital X in the flag (ssh -X) and not the lowered case one that
> > you're posting.
> yes, you got it right.
> >
> > The body of your message suggests you're having a problem with a
> > x-server on Windows, that is not reproducible on linux? and you're
> > blaming NetBeans for that. Also there's no stack trace or any other
> > hint of the problem you're having that explains why you think NetBeans
> > is failing in your setup.
>
> Sorry for the confusion. The crash on Windows can be reproduced
> relatively often when pressing the toolbar button for git push. It is
> far less likely, when Netbeans - menus are used.
>
> Let's rephrase my questions. Hopefully there is a better understanding.
>
> Does anyone has experience with Netbeans running on an remote X-Server,
> including Windows X-Client? (working feedback would be awesome)
>
> Is there a difference between using the Toolbar button and calling a
> feature through the menu? Maybe different code is called that is causing
> a difference on the X-Server.
>
> I do not blame Netbeans. MobaXterm is the software that crashes. The
> whole case is odd, and I am following leads.
>
> >
> > I suggest you redacting your email properly, adding more information,
> > at the risk of being ignored in this mailing list.
>
> Thanks for helping improving my inqurie.
>
> All the best
>
> Peter
>
> >
> >
> > On 4/5/23 21:01, Peter Kovacs wrote:
> >> Hello all,
> >>
> >> Following situation: for a complex web service I have moved a
> >> development environment (Netbeans + PHP module) on server. Devs on
> >> Windows experience now crashes when using buttons on top for push, pull.
> >>
> >> Menu seems less affected.
> >>
> >> Does anyone has experience with this sett up? Is there a difference
> >> between buttons in main windows or if I use the git menu?
> >>
> >> How do i find the implementation in the code?
> >>
> >> Any idea how to debug this?
> >>
> >>
> >> All the best
> >>
> >> Peter
> >>
> >>
> >> -
> >> 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
>
>
>
>

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

[László Kishalmi]

Well, your proposal is actually putting additional work both on who wants
to move forward and who wants to support Java 8 runtime. Also how would it
look like wne Java 17, 21 would be the base? I would like to avoid having
codes in the ide like this one:
https://github.com/apache/netbeans/blob/7f8dfdeb60ce3bec5554fc19ddb40fac0388d885/extide/gradle/netbeans-gradle-tooling/src/main/java/org/netbeans/modules/gradle/tooling/NbProjectInfoBuilder.java#L1090

And also not everything is coming through Lookup. Yes additional interfaces
could be introduced, yes. This could work in a small scale, in a model
where we have a Java 8 runtime as standard and eventually offer some
services to those who run it on Java 11+.

Well, I know the feeling, I was still running NetBeans on Java 1.4.1 on
OS/2 in 2005. It was not easy to let it Go. However I do not think that
there is any scarification that would need to happen. Create a branch from
the upcoming NetBeans 18, backporting some PR-s and occasionally release a
NetBeans 18.1 18.2 could happen for years. I do not think that anyone would
turn their face away, if there would be a request to help that effort every
now-and-then.

The VOTE thread is open, please cast your vote there.


On Tue, Apr 11, 2023 at 8:32 PM Jaroslav Tulach 
wrote:

> > With all due respect, that's not an "alternative".  It took me two
>
> I believe my proposal is a real alternative and it is a way to move us
> forward
> while not giving up on what makes NetBeans Platform unique - while not
> giving
> up on backward compatibility.
>
> > reads to distinguish it from the status quo that we've been doing for
> > the last 18 months.  Even then, in practical terms, it's the same.  If
>
> The core of my alternative proposal is to move forward and support newer
> JDKs
> properly, where needed via the "Run on JDK8, use JDK11 APIs!" - http://
> wiki.apidesign.org/wiki/AlternativeImplementation
>
> Are you saying we are using this proposal already for last 18 months? I am
> not
> aware of that! If I am mistaken, then please point me to few PRs that are
> implementing the "Run on JDK8, use JDK11 APIs!" technique!
>
> I haven't seen this "Run on JDK8, use JDK11 APIs!" used yet! To let us
> start,
> please give me three problems that could be solved by using JDK 11 APIs
> and
> I'll create a PR showing how to do that properly via the "Run on JDK8, use
> JDK11 APIs!" style. You will all see, it is a simple and viable way to
> move
> forward. Then we can all copy that approach where needed and you can focus
> on
> what you care about...
>
> > maintenance of the JDK 8 tests is something
>
> ...none of you wants to do. I understand that. You want to focus on what
> you
> like. Great, go on and focus fully on new JDKs. I'll maintain the old
> modules/
> tests for you.
>
> I don't find that particularly fascinating, but NetBeans Platform backward
> compatibility is so close to my heart that I am going to sacrifice myself
> and
> do this dirty work. At the end, keeping exiting, functional code running,
> isn't going to be that much work.
>
> TL;DR: If my alternative proposal is accepted, we'll start doing things
> differently and allow the NetBeans project to move forward while keeping
> its
> heritage and compatibility.
>
> Best regards.
> -jt
>
>
> Dne čtvrtek 6. dubna 2023 10:16:14 CEST, Neil C Smith napsal(a):
> > On Wed, 5 Apr 2023 at 16:13, Jaroslav Tulach 
>
> wrote:
> > > 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
> >
> > With all due respect, that's not an "alternative".  It took me two
> > reads to distinguish it from the status quo that we've been doing for
> > the last 18 months.  Even then, in practical terms, it's the same.  If
> > that was actually working and sustainable, we wouldn't be having all
> > the discussion on this in the first place.
> >
> > It doesn't address any of the main concerns.  It's already been
> > pointed out that the maintenance of the JDK 8 tests is something of a
> > red herring (I would point out you made a similar promise under the
> > current policy, but didn't input into the EE 10 issue raised in the
> > background).
> >
> > - How do we handle the issue of currently non-optional modules that
> > require JDK 11+, and who is doing the actual work to split them into
> > alternative implementations?  What happens if there is no viable JDK 8
> > implementation?
> > - How do we address the issue of older / unsupported dependencies (eg.
> > Lucene, but more inbound) that require a higher JDK?  Who is going to
> > do that work?
> > - How do

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

[László Kishalmi]

+1 (binding)

On Tue, Apr 11, 2023 at 6:08 AM Brad Walker  wrote:

> +1
>
> -brad walker
>
> On Tue, Apr 11, 2023 at 2:23 AM Neil C Smith 
> wrote:
>
> > # 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 would be free to adopt the minimum JDK as
> > they need to.
> >
> > * Optional modules may continue to require a runtime JDK higher than
> > the minimum.  Should it become necessary, build time optional modules
> > might be considered - eg. a build on the minimum JDK may exclude
> > modules that will not run on that JDK at runtime.
> >
> > * Some modules that are of independent use (eg. lookup, utilities,
> > etc.) might be nominated and advertised to continue JDK 8 support for
> > the time being. This is not expected to cover the runtime container as
> > a whole -
> https://netbeans.apache.org/tutorials/nbm-runtime-container.html
> >
> > * Once NetBeans 19 is released, the NetBeans 18 release branch could
> > be used to backport and release JDK 8 supporting fixes, subject to any
> > PMC members wanting to manage those releases.
> >
> > * The term "platform" is used in reference to the whole framework of
> > modules that we release (eg. via Maven), not just the platform
> > cluster.
> >
> > [1] https://github.com/apache/netbeans/pull/4999
> > [2] https://github.com/apache/netbeans/pull/4692
> >
> >
> > ## Procedure
> >
> > This vote is going to be open at least 72 hours.  Vote with +1, 0, and
> -1.
> >
> > Please mark your vote as binding only if you're an Apache NetBeans PMC
> > member to help with voting admin.
> >
> > Decision will be by majority vote, with at least 3 binding positive
> votes.
> >
> > 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: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)

[László Kishalmi]

Well, there is no hatred here, it is a heated debate.

It's just beyond my understanding that people with 20+ years of software
development experience don't see branching as a viable option.

It seems we could not have convinced some of us on our proposal, that's sad.

I'm getting tired of this debate, and I think I'm not alone with that.
Let's do an official vote then.

On Mon, Apr 10, 2023 at 10:41 AM 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.
>
>
> -
> 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: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)

[László Kishalmi]

On Mon, Apr 10, 2023 at 7:26 AM Karl Tauber  wrote:

> +1
>
> On 10.04.2023 14:08, Svata Dedic wrote:
> > I am advocating not to drop JDK8 as runtime for NetBeans (extended)
> > Platform, as that decision affects NetBeans-based applications.
> > Microchip IDE, that mining analytic stuff we had presentation a long
> > time ago (but that still IMHO lives), and possibly others.
> >
> > Changing the _runtime_ requirements for NetBeans platform affects
> > application builders - they are often being forgotten in discussions.
>
> Do we know that those applications are planing to upgrade to
> newer/future NetBeans Platform versions? If none of them plan to
> upgrade, then the whole discussion is useless...
>

+1, also what do they get from JDK8 updates? Last time half of the change
was patching some tests, there were a few security patches for jars signed
with SHA1 and the update of TZ data.
I'd imagine, no one is upset that the Virtual Thread feature was not
backported...



> I think, if a project/application decides to stay with Java 8 because it
> is to risky or to expensive to upgrade to Java 11+, why should they
> upgrade to a newer NetBeans Platform version? Any upgrade has some risks
> and costs. Isn't it more likely that they newer upgrade to latest
> NetBeans Platform version?
>
>
> Or the other way around:
> if a project decides to stay on 9 year old Java 8, why can't they stay
> on NetBeans Platform from 2023?
>
>
> We can't stay forever on Java 8 just because some NB platform
> applications still use Java 8 and "maybe" want upgrade to latest NB
> version.
>
>
Also what would happen if Karl decides to pull the plug on Java 8 for
FlatLAF? Just think about it...

There is a way to support old software, and that is called branching.
It is that simple.

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

[László Kishalmi]

Well this is about the Lazy Consensus then.

I think Neil summarized a plan with a soft, but defined step away option
from JDK 8. It offers more compromise than some of us would like on this
front.

Also no one of the naysayers provided a sane use case why that offer should
not work for them. It's easy to say no, in the name of a holy idea, but
would some of you present a case:
1. I have this platform application built on top of NetBeans 17 (or 18),
that needs to run on JDK 8, if NetBeans 19 would only run on JDK 11, I
would face issues, as I depend on this and that modules, that I *must*
upgrade to.
2. I have an android application that uses some NetBeans Core modules. My
life would be ruined if I can get the apidoc changes
org.netbeans.swing.outline from the next release

Something like this.

On Wed, Apr 5, 2023 at 1: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 

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

[László Kishalmi]

+1

On Tue, Apr 4, 2023 at 7:36 PM Brad Walker  wrote:

> +1
>
> -brad w.
>
>
>
> On Mon, Apr 3, 2023 at 4:39 AM Neil C Smith  wrote:
>
> > As mentioned elsewhere, I'm kicking off a process to bring this issue
> > to a decision.  For various reasons, having a decision before we
> > branch off NB18 is desirable.  I've drawn up a draft proposal (below)
> > that tries to encompass most of what has been expressed, and hopefully
> > achieves that - thanks to those who have already given feedback in its
> > iteration.
> >
> > This thread will be active for 7 days.  Expressions of support and
> > disagreement welcomed.  In particular, if you -1 please offer an
> > alternative to all or part of this proposal that you're able to help
> > implement.  We should try and reach a consensus position that removes
> > any block.  If after the 7 days we cannot do this, then we move to a
> > vote on this with any agreed amendments.
> >
> > See also the page at
> > https://community.apache.org/committers/consensusBuilding.html
> >
> > Thanks, Neil
> >
> > 
> >
> > # 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 would be free to adopt the minimum JDK as
> > they need to.
> >
> > * Optional modules may continue to require a runtime JDK higher than
> > the minimum.  Should it become necessary, build time optional modules
> > might be considered - eg. a build on the minimum JDK may exclude
> > modules that will not run on that JDK at runtime.
> >
> > * Some modules that are of independent use (eg. lookup, utilities,
> > etc.) might be nominated and advertised to continue JDK 8 support for
> > the time being. This is not expected to cover the runtime container as
> > a whole -
> https://netbeans.apache.org/tutorials/nbm-runtime-container.html
> >
> > * Once NetBeans 19 is released, the NetBeans 18 release branch could
> > be used to backport and release JDK 8 supporting fixes, subject to any
> > PMC members wanting to manage those releases.
> >
> > * The term "platform" is used in reference to the whole framework of
> > modules that we release (eg. via Maven), not just the platform
> > cluster.
> >
> > [1] https://github.com/apache/netbeans/pull/4999
> > [2] https://github.com/apache/netbeans/pull/4692
> >
> > -
> > 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: Launching an application

[László Kishalmi]

Snap cannot depend on system packages. It may depend on other snaps as
content packs, however that would only in a sandboxed environment. (We are
not sandboxed at the moment).
It would be possible to package a downloaded JDK along with the Snap or
have one downloaded during the install phase. However then comes the
question: which one?

On Tue, Apr 4, 2023 at 10:22 AM Neil C Smith  wrote:

> On Tue, 4 Apr 2023 at 18:12, Andrii Cherepkov 
> wrote:
> > Yes, I know that NetBeans uses JDK and I need to install that.
> > But I said about users who don't know about that. Whey is not seeing any
> > popup windows in Linux like Ubuntu.
>
> Because it's not as simple an ask as it is on Windows.
>
> Does the Snap list a dependency on a JDK?  Not sure whether the Snap
> has a hard or recommended dependency?
>
> 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: Version for 32bit

[László Kishalmi]

We do not provide a 32 bit installer.

However you can download the zip distribusion, unzip it and run. It can run
with 32 bit Java.

On Fri, Mar 31, 2023 at 11:38 AM Allan Muzimba 
wrote:

> Hi, my name is Allan and I am a php developer, I am currently using the old
> version of netbeans 8.1; I would like to upgrade to Netbeans 14 with C++.
> Problem, *I use 32bit windows 8,* and I have tried to download on Apache
> for version 14, but the version package keeps saying it is not supported.
> Can you provide with a link to download Netbeans 14, 32bit please
>

Rust, Lexer Issues

[László Kishalmi]

Well, this one is mostly for Antonio.

At the beginning of the Rust, anyone thread you were hitting some assertion
errors in LexerInput.
I have not seen the stacktrace, but I'd guess that's due to the original
error handling in ANTLR.

Is that true? Is that the reason why:
https://github.com/apache/netbeans/blob/5934827e80797ec9b93ff28635ce7fca12627a70/rust/rust.grammar/src/org/netbeans/modules/rust/grammar/RustLanguageLexer.java#L80
has been put in code?

I'm asking because I'm hitting the assertion in my recent HCL Lexer and
suspect the default ANTLR error handling as a source. So this just would
reassure me, and also can replace the default error handler in the
AbstractAntlrLexerBridge.

BTW, Thanks for moving the Rust effort!

Re: Rust, anyone?

[László Kishalmi]

I'd vote for b.4 by Neil.

On Thu, Feb 16, 2023 at 12:02 PM Chris  wrote:

> Hey all,
>
> as far as I can remember, under oracle there was a time where we had a
> similar process to continous deployment. That means, that it was also
> possible, to release bugfixes inside the core and updates of plugins
> from the core between releases. Sometimes I opened NetBeans 7.1 and
> after weeks I got the info "there are updates" no 3rd-party-plugins, no
> 7.1 to 7.2. It was just that I had the HTML editor 1.1.1 -> 1.1.2 (just
> an example, not the correct version). So what is with those approaches?
>
> I would like to see as many stuff as possible inside the core and yes we
> have problems of updating stuff, when we wait for a new release. So is
> it possible to have such continous deployment after a PR was merged and
> all tests are green, in between releases? That means for me, we can have
> everything inside the code, rust, go, whatever and have also bugfixes
> and new small features. Is this not possible under apache?
>
>
> Cheers
>
> Chris
>
> Am 16.02.2023 um 10:20 schrieb Neil C Smith:
> > Hi,
> >
> > On Thu, 16 Feb 2023 at 07:02, Antonio 
> wrote:
> >> a) I don't think Rust support is ready yet to be merged with core:
> > ...
> >> b.2) Create a repo of ours and let "rust" be an experimental plugin, and
> >> keep on improving it there.
> > b.4) might be to merge into master as a separate cluster, or in an
> > experimental cluster, and not include in the release list of clusters?
> >
> > Can see pros and cons to both approaches.  Having somewhere we could
> > develop and release (experimental) plugins from might be good.  Having
> > the development happen here also good.
> >
> > Personally see far more reason to eventually include Rust in core than
> > some of the more product oriented things we do have in there that
> > should have been kept as plugins IMO.
> >
> > 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: Rust, anyone?

[László Kishalmi]

That could be due to virtual tokens (ANTLR token with no length)

Maybe I've done something insufficient here:
https://github.com/apache/netbeans/blob/15ad55e3f28727e64a4642971f3a980b538c6d4d/ide/lexer.antlr4/src/org/netbeans/spi/lexer/antlr4/AbstractAntlrLexerBridge.java#L152

On Mon, Feb 13, 2023 at 11:52 AM Antonio  wrote:

> Hi,
>
> Well, the Antlr4 lexer/parser works pretty well, but from time to time
> it throws an AssertionError [1] and freezes NetBeans, so it needs more
> work. Detecting test cases (by opening random Rust projects) and
> detecting where things break is useful.
>
> But there're lots of things to do: improve syntax coloring (macros, for
> instance, could be in another color, and numbers), add code folds for
> structs, etc.
>
> Cheers,
> Antonio
>
> [1]
>
> https://github.com/apache/netbeans/blob/c084119009d2e0f736f225d706bc1827af283501/ide/lexer/src/org/netbeans/spi/lexer/LexerInput.java#L257
>
> On 13/2/23 19:33, Jakub Herkel wrote:
> > Antonio, is there any list of things that you want (need) to
> > implement? Maybe someone (me also) can take some of them.
> >
> > Jakub
>
> -
> 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: Rust, anyone?

[László Kishalmi]

It says: It is recommended to rewrite/migrate the plugin to ANTLR4 and LSP.

On Sun, Feb 12, 2023 at 11:08 PM John Kostaras  wrote:

> Hello there. There has already been something about Rust
> 
> (written
> in JavaCC).
>
> Ioannis.
>
>
> On Sun, Feb 12, 2023 at 10:18 AM Antonio 
> wrote:
>
> > Thanks Michael!
> >
> > D'oh! My intents to add Rust to the NetBeans core (very much as in the
> > Linux kernel case) have been detected! :-D
> >
> > Latest commits solve these issues, though (and add new bugs).
> >
> > Next challenge: Cargo workspaces [1].
> >
> > Cheers,
> > Antonio
> >
> > [1] https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html
> >
> > On 12/2/23 9:03, Michael Bien wrote:
> > > for others who want to give it a try: I had to fix two things to make
> > > the build pass:
> > >   - removed references of RustPackage in org.openide.nodes.Node
> > > (probably a happy coding accident)
> > >   - had to create this folder: netbeans/rust/rust.project/test/unit/src
> >
> > -
> > 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

[László Kishalmi]

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 
> version
> >> of NetBeans you can report this
> >> , 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?

[László Kishalmi]

Yes. I'd wished to reply on the Gradle 8.0-rc-5 issue thread.

On Mon, Feb 13, 2023 at 8:41 AM Scott Palmer  wrote:

> 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 <
> laszlo.kisha...@gmail.com>
> 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?

[László Kishalmi]

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: [RELEASES] Preparing for 17-rc3

[László Kishalmi]

No problem. We will see then.

On Thu, Feb 2, 2023 at 2:06 AM Neil C Smith  wrote:

> On Thu, 2 Feb 2023 at 03:33, László Kishalmi 
> wrote:
> > Can we delay the race with 1-2 days? It's usually Thursdays when Gradle
> > publishes it's releases as well. While I do not think that they will
> > announce a 8.0 GA after just two rc-s, but it may worth to look if
> > something is changed.
>
> Sorry, we've already synced, and in theory* published.
>
> We should certainly consider another rc if we get a Gradle update or
> GA anyway.  It's rare we don't end up with an rc4.  Although if it
> comes later, there's always updates! :-)
>
> There's a bunch of things in rc3, not to mention some fun with
> syncing, that make this good to get done on time.
>
> * Jenkins build 18 ran fine and published to nightlies already
> yesterday.  Then something triggered an automated build 19 that has
> some errors in it.  So I've triggered a manual build 20 and 17-rc3
> won't be properly announced until later today now.
>
> 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: [RELEASES] Preparing for 17-rc3

[László Kishalmi]

Can we delay the race with 1-2 days? It's usually Thursdays when Gradle
publishes it's releases as well. While I do not think that they will
announce a 8.0 GA after just two rc-s, but it may worth to look if
something is changed.

On Wed, Feb 1, 2023, 03:02 Neil C Smith  wrote:

> Hi,
>
> I've merged all remaining open and ready PRs to delivery.  I plan to
> sync to release170 later today and then trigger a build of 17-rc3.
>
> This will be the last release candidate unless something high /
> critical priority is reported.  Speak up now if you think anything has
> been missed!
>
> Delivery is now closed for merging unless a high / critical priority
> PR comes through.
>
> Thanks and 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: [slack] Is it still used?

[László Kishalmi]

Yes, a few of us are regularly on-line, trying to help each other.

Our non:official Telegram group is also growing, recently got our 500th
member, though many of them are students trying to learn Java and sometimes
NetBeans.

On Wed, Feb 1, 2023, 08:36 Michael Bien  wrote:

> slack is still there. I see you online right now, what is the problem? ;)
>
> slack was running some more aggressive ads recently for communities
> which use the free option. Doesn't surprise me that this causes some
> confusion.
>
> -mbien
>
> On 01.02.23 17:15, Jean-Marc Borer wrote:
> > Hello,
> >
> > I am not really used to Slack so pardon me if my question seems obvious.
> >
> > I saw that there is a Slack community about netbeans. I joined it, but
> > noticed a trial period count down. I suppose it is related to the space
> > itself and not my membership.
> >
> > Now it has expired.
> >
> > Is Slack still actively used by the community or was it just a trial?
> >
> > Apart from the mailing lists are there other locations "a la" Slack to
> > discuss NB topics. Github?
> >
> > Best regards,
> >
> > JMB
> >
>
>
> -
> 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

[László Kishalmi]

I think you are hitting a series of "edge" cases. I put the edge in quotes
as, most probably, they shouldn't be.

1. I've seen the CRC32C exception in Gradle from time to time, especially
when dealing with modular applications.
2. Yes it's true Java Toolchain is not fully supported in NB17, the
bootclasspath would be always the Gradle Runtime boot CP
3. Due to these, or totally independently the Javac let you down with an NPE

Again a minimal reproducible project would be good, but this is a nasty one.


On Mon, Jan 30, 2023 at 7:11 AM Scott Palmer  wrote:

> 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 Gradle "included builds" are missing from class path

[László Kishalmi]

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  >
> 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
> > >
> >
>

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

[László Kishalmi]

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
>

Re: Better release notes for NB17 - the Highlight label

[László Kishalmi]

Let's bring the "New and Noteworthy" page back! If we start now we might
have one ready by the time of the release!

I'd do the Gradle section, I guess my ANTLR work in this release is not
that interesting for the public.

On Tue, Jan 24, 2023 at 11:29 AM Michael Bien  wrote:

> I had the same thought. But wasn't sure if that is a good idea since the
> compact nature of release notes can be a feature in itself.
>
> The release highlights (new-and-noteworthy as NB used to call the page)
> with screenshots and clips is more something for blogs/wikis I believe.
>
> -mbien
>
>
> On 24.01.23 20:22, Eirik Bakke wrote:
> > I think screenshots might help a lot in creating more appealing Release
> Notes. Often, screenshots from the PR can be reused. And we can always
> encourage people to attach screenshots in PRs when relevant.
> >
> > -- Eirik
> >
> > -Original Message-
> > From: Neil C Smith 
> > Sent: Tuesday, January 24, 2023 11:28 AM
> > To: Michael Bien 
> > Cc: dev@netbeans.apache.org
> > Subject: Re: Better release notes for NB17 - the Highlight label
> >
> > On Tue, 24 Jan 2023 at 16:11, Michael Bien  wrote:
> >> We can manually group the changes a bit better in the final release
> >> notes - just like Laszlo did with the Editor category of NB 16. Since
> >> its often that multiple PRs when taken together would create a
> >> noteworthy change.
> > Agreed!  Although this is also how we (OK, mainly Geertjan! :-) )
> highlight things on the download pages, blog posts, social media posts, etc.
> >
> > Compare eg. https://netbeans.apache.org/download/nb120/index.html and
> https://netbeans.apache.org/download/nb16/
> >
> > The former was definitely becoming burdensome, but the latter is
> possibly not enough.
> >
> >> FlatLAF update PR quietly introduces a new theme (highlight label
> worthy):
> >> https://github.com/apache/netbeans/pull/5298
> > ...
> >> (some?) PHP 8.2 support - but the PRs are already nicely grouped in
> >> that category
> > Good list! :-)
> >
> >> but tbh as someone who is often going around and labels PRs, I am
> >> already glad when they are labeled at all :) I am not really thinking
> >> about release notes at this point in the dev cycle.
> > Tell me about it!  That's kind of the issue, along with grouping, where
> maybe the highlight label is not the right way to do this?
> >
> > 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
> >
> >
> >
>
>
> -
> 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

[László Kishalmi]

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: Prepare for more Gradle tweaks

[László Kishalmi]

Thanks!

Going to file a PR soon>
BTW: Gradle 8.0-rc-1 is on master.

On Tue, Jan 10, 2023 at 4:30 PM Scott Palmer  wrote:

> 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: [NOTICE] - Freeze and branch for Apache NetBeans 17 on January 18th

[László Kishalmi]

No it's based on master. 16-u1 was a release with a few PRs backported over
NB16

On Tue, Jan 10, 2023 at 12:37 PM Eric Bresie  wrote:

> Is this based on 16-u1?
>
> On Fri, Jan 6, 2023 at 8:21 AM Neil C Smith  wrote:
>
> > Hi All,
> >
> > This is advance notice that we're intending to freeze and branch for
> > NetBeans 17 on January 18th.
> >
> > As we wind down towards NetBeans 17, please help with reviewing
> > remaining pending pull requests by January 17th.
> >
> > Please be release aware - merged PRs should be ready for release and
> > not require follow up.  If in doubt, push back to NB18.
> >
> > https://github.com/apache/netbeans/milestone/20
> >
> > Also, please help with triaging issue reports, and mark with NB17
> > anything that might be high or critical priority for the release.
> >
> > We're intending to create the delivery and release branches on January
> > 18th.  All remaining open PRs will be retagged to NB18.  Anything that
> > requires merging to NetBeans 17 after that date should be opened /
> > rebased against delivery for review.
> >
> > A first release candidate should be available by January 19th, with
> > weekly release candidates until the release vote.
> >
> > Thanks all and 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
> >
> >
> >
> > --
> Eric Bresie
> ebre...@gmail.com
>

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

[László Kishalmi]

Well, I think we can remove the CV for Java 8.
Probably the only Java 8 thing we shall do is make sure that the platform
sources can be compiled and tested on Java 8.


On Tue, Jan 10, 2023 at 7:28 AM Michael Bien  wrote:

> On 10.01.23 16:25, Ernie Rael wrote:
> > On 23/01/10 6:16 AM, Michael Bien wrote:
> >>
> >>
> >> Given that NB doesn't really support running on JDK 11 since a while
> >> I would simply opt for 2) and merge.
> >>
> >>
> > Typo? JDK-11 --> JDK-8
>
> yes, thanks for spotting this!
>
> -mbien
>
> >
> > -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: Two questions

[László Kishalmi]

Dear name,

That's a pretty ambitious plan. You are free to do that, though if you
would like to contribute that work back, you need to have the support of
the Apache NetBeans Project Management Committee.

NetBeans is officially built on JDK11. As the platform is used several
places we keep that part on Java 8 compatibility.
It is also possible to Build NetBeans on Java 17, 18 and after a Gradle
upgrade on Java 19 as well.

Migrating NetBeans build system to Gradle is a hard and non-trivial task,
yet a noble effort. A few years back I was able to compile all the Platform
with Gradle, however, the tests failed at the introduction of the first
OSGI module.

Good luck with your efforts, and report back your progress!

On Fri, Jan 6, 2023 at 8:32 AM name name2  wrote:

> Hello
>
> I want to migrate NB to gradle and jdk 17. Is it possible or some customers
> hardlocking version at 1.8 and ant tool?
>

Re: [DISCUSSION] DevOps Cluster?

[László Kishalmi]

Well,

@Eric Bresie 
I usually do not enable the Enterprise cluster on my work NetBeans, and
Java SE + Groovy is only enabled as we have Jenkins in Job DSL. Anyway, I
think the Enterprise cluster is bloated already.

Yes, there are some things available as LSP, but if I'd just use that I
could use VS Code as well.

@Eric Barboni 
Yes, if there were support for Ansible or Puppet, those would belong there.

Yes, the new modules can be put into existing clusters, the question would
be which one and why.

@Michael Bien 

Well, that wouldn't be the "generic project" idea, rather than some shared
project infrastructure code between Terraform and Helm, though that
"generic project" could come out of that.

Also till a point ide cluster is fine, and from a point it might be weird.
I feel that with docker now. The editor support is fine, Dockerfiles are
common enough. The other docker integrations however could go somewhere
else. (Those features not that useful, and probably need some love)


Let's step back and ask, what requirements need to be fulfilled to have a
new cluster.
Also what things are against creating a new cluster.

On Thu, Jan 5, 2023 at 4:30 AM Eric Bresie  wrote:

> Would any of that fall under the enterprise cluster which has some “cloud”
> functionality (Amazon. or is that too overloaded) or ide which has some
> container (docker)?
>
> So is a LSP server an option for some of this? There seem to be a few
> servers available for Terraform
> https://microsoft.github.io/language-server-protocol/implementors/servers/
>
> Get Outlook for iOS
> 
> From: Eric Barboni 
> Sent: Thursday, January 5, 2023 3:52:25 AM
> To: dev@netbeans.apache.org 
> Subject: RE: [DISCUSSION] DevOps Cluster?
>
> It could be nice.
>
> I'm not very aware of the scope but ansible or puppet could belongs to
> this cluster ? (no intend to do plugin 😝)
>
> Best Regards
> Eric
>
> -Message d'origine-
> De : Michael Bien 
> Envoyé : jeudi 5 janvier 2023 09:01
> À : dev@netbeans.apache.org; Laszlo Kishalmi 
> Objet : Re: [DISCUSSION] DevOps Cluster?
>
> sounds awesome,
>
> comments inline.
>
> On 04.01.23 16:48, Laszlo Kishalmi wrote:
> > Dear all,
> >
> > As many of you know, I'm a DevOps Engineer by trade (whatever that
> > means). I use NetBeans daily, however beside supporting Text editing,
> > terminal and favorites to organize my work. Text editing is mostly
> > Terraform and sometimes YAML.
> >
> > One day, I spent good time, when I edited code in a long comment
> > block, trying to troubleshoot why my changes were not applied. That
> > would be obvious if I had basic syntax highlight for Terraform.
> >
> > I wanted to create a syntax highlight module for Terraform. I checked
> > the available HCL grammars written in Java, I was not convinced
> > enough. That lead to ANTLR support in NB16.
> >
> > So, I have an ambitious plan creating a set of plugins which actually
> > would help my work:
> >
> >  - Support for Helm Charts: That would mean Helm Charts would open as
> > NetBeans Projects, main goal would be providing code completion in the
> > Yaml templates.
> >
> >  - Editor Support for Terraform files: syntax highlight, code
> > templates
> >
> >  - Terraform Project Support: Terraform files to be parsed, and
> > provide code completion on the parsed data.
> >
> >  - Go Lang Support: Well, this is not to express my love for GoLang
> > (as there are none of that), but Terraform resource/datasource
> > metadata can be extracted from the original source code. I just need a
> > parser.
> >
> > What I have so far:
> >
> >  - Initial code for Go. (ANTLR based Lexer/Parser, basic Syntax
> > Highlight)
> >
> >  - Initial code for Terraform (ANTLR based Lexer/Parser, basic Syntax
> > Highlight, Code Templates)
> >
> >  - Some code for Helm project support, that does not provide anything
> > useful in its current state.
> >
> >  - A General DevOps project type, I plan to use for Helm and Terraform
>
> long ago I wrote a "generic project" type which simply put a folder into
> the project tree (and automatically removed anything in .gitignore).
> This sounds like something similar.
>
>
> >
> > These kind of modules do not fit into our existing clusters, so I'd
> > propose to create a devops cluster.
>
> i mean it could be also put into the ide cluster next to docker etc. No?
>
>
> >
> > I'm not sure what should be the development model for this, as there
> > would be half baked modules for a while, so going right into master
> > may not be feasible as some implementations would be arching over a
> > few NB releases. Though I wish to file multiple PR-s gradually, not
> > just one big bang.
> >
> > I'm thinking about the following options:
> >
> >  - Create a devops cluster in a devops branch in the main repo, create
> > PR-s agains that branch, merge to master when it's solid.
> >
> >  - Create a devops cluster in master branch, create PR-s as usual, do
> > not include/mark 

Re: Markdown coming to Javadoc comments

[László Kishalmi]

Sure we need to write the support for that.

On Wed, Jan 4, 2023 at 10:56 AM John Neffenger  wrote:

> I always thought it would be nice to be able to use Markdown in Javadoc
> comments, but this was a big surprise!
>
> JDK-8298405: Markdown support in the standard doclet
> https://github.com/openjdk/jdk/pull/11701
>
> It's targeted for JDK 21. Will NetBeans need to do anything extra to
> support this feature?
>
> 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: [External] : RE: [DISCUSSION] Gradle Patch Release for NetBeans 16

[László Kishalmi]

Go on!

On Sun, Dec 18, 2022 at 12:03 PM Svata Dedic 
wrote:

> Hi,
>
> late Friday, a colleague discovered a bug in NbProjectInfoBuilder -
> mishandled compiler options (compilerArgs / allCompilerArgs /
> freeCompilerArgs) that fails to load the project when NB runs on JDK19.
> I can provide a fix tomorrow.
>
> -S.
>
> On 18. 12. 22 18:28, Neil C Smith wrote:
> > On Sun, 18 Dec 2022 at 16:58, Laszlo Kishalmi 
> wrote:
> >> I'm ready to update the netbeansrelease.json. In the 12.0-u1 and 12.0-u2
> >> it was just another entry with git hash, version and position. Would it
> >> be the same this time, or shall I use the vote entry as well. As far as
> >> I remember vote would remove the version suffix from the final artifacts
> >> and other places, that might be not required for 16-uc1.
> >
> > Yes, try as before and leave out vote.  That does very little now, but
> > I think will still stop the version suffix being added.  Eric even
> > better to answer that!  Quite a lot has changed since we did 12.0
> > updates, but all should hopefully work OK.
> >
> > Try to update netbeansrelease.json after merging and before building
> > if you can.  The build process also publishes to
> > https://nightlies.apache.org/netbeans/candidate/netbeans/ now which
> > currently has your build without a suffix.  Aside - we should look at
> > adding -dev as suffix to files for this as fallback.
> >
> > Nightlies might be a better update centre to share for testing too if
> > we need to in future.
> >
> > 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: [External] : RE: [DISCUSSION] Gradle Patch Release for NetBeans 16

[László Kishalmi]

Hi Neil!
I have not planned another build, just with the one with the updated
netbeansrelease.json.
I was swamped with work this week, so I need to assess the situation and
feedback during the weekend.

Both mentioned feature requests are doable for NB17

On Fri, Dec 16, 2022 at 2:03 AM Neil C Smith  wrote:

> On Fri, 16 Dec 2022 at 07:31, Ernie Rael  wrote:
> > On 22/12/15 9:34 AM, László Kishalmi wrote:
> > > Went ahead and merged the delivery to the release160 branch. The
> update can
> > > be tested by adding the following update center URL:
> > >
> > >
> https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/netbeans/job/release160/14/artifact/dist/netbeans/nbms/updates.xml.gz
> >
> > Still running NetBeans on JDK-11
> > Inalled update with plugin manager
> >  Once it is installed, there doesn't seem to be a way to tell from
> > the plugin
> >  manager that I'm using the new stuff, but
> >  org.netbeans.modules.gradle/2 [2.29.1
> > Netbeans/netbeans-TLP/netbeans/release160-14-on-20221215]
> >  org.netbeans.modules.gradle.java [1.20.1.1
> > Netbeans/netbeans-TLP/netbeans/release160-14-on-20221215]
>
> Will do some testing.  Laszlo, I assume you're already planning
> another build before vote?
>
> In case not, the hash and version needs to go into
>
> https://github.com/apache/netbeans-jenkins-lib/blob/master/meta/netbeansrelease.json
> before the build for the vote is triggered.
>
> Comment initially prompted by seeing the above implementation / build
> version with date rather than hash showing up.  That actually appears
> to be another issue.  As far as I can tell we have a bunch of modules
> where the implementation version in the update centre is different to
> the IDE build?!
>
> > BTW, it would be nice if the gradle version of the project was display
> > somewhere in the project's properties.
>
> +1.
>
> +2 if the UI supported updating the Gradle project wrapper next to that!
> :-)
>
> 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: [External] : RE: [DISCUSSION] Gradle Patch Release for NetBeans 16

[László Kishalmi]

Thanks for your understanding!

Went ahead and merged the delivery to the release160 branch. The update can
be tested by adding the following update center URL:

https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/netbeans/job/release160/14/artifact/dist/netbeans/nbms/updates.xml.gz
On 12/13/22 07:37, Martin Balin wrote:

Hello,
Most of the fixes there are related to VSNetBeans, although related to
Gradle or projects infrastructure. I understand your intention was
about Gradle update itself to the latest version. If listed PRs are
too much then these can wait and I will do VSNetBeans 16.0.301 in
January. Not making 16u1 too big, no problem.

Martin


On 12. 12. 2022, at 23:42, Laszlo Kishalmi 
 wrote:

Dear all,

It seems my request went a bit too well, for my like. There are a few
enhancements marked, which I think would be better to leave for NB17.
(https://github.com/apache/netbeans/pulls?q=is%3Apr+is%3Aclosed+label%3A16u1
<https://github.com/apache/netbeans/pulls?q=is%3Apr+is%3Aclosed+label%3A16u1>
<https://github.com/apache/netbeans/pulls?q=is%3Apr+is%3Aclosed+label%3A16u1>)

I've planned NB16u1 just to iron out the wrinkles in the Gradle
support, release it quick and distribute that an an NBM. I hope you
understand and don't mind, I'd not include those enhancements for now.
It's my fault not communicating this clear enough, so I give some time
and hear your voice in that. I'm sorry.

Otherwise the delivery branch is almost ready (the version bump is missing).
https://github.com/apache/netbeans/pulls?q=is%3Apr+milestone%3ANB16u1+is%3Aclosed
<https://github.com/apache/netbeans/pulls?q=is%3Apr+milestone%3ANB16u1+is%3Aclosed>
<https://github.com/apache/netbeans/pulls?q=is%3Apr+milestone%3ANB16u1+is%3Aclosed>


On 12/5/22 19:53, Laszlo Kishalmi wrote:

Well,

I'd like to do this ASAP, if my time allows, I'd kick off the vote
later this week.

We are probably ready wit the PR-s on master. I'd reuse the delivery
branch to collect the addendum to NB16, then will merge at once in
release160.

Since the milestone is NB16u1, let's mark your the wished PR-s with
"16u1" label.

I'm going to create cherry-picked PRs from those, and remove the label
when the PR is ready for NB16u1 milestone.

On 12/1/22 10:53, Martin Balin wrote:

Hi,
Any date in mind for this release? Lazslo, release before Christmas
break or after?
I propose to label PRs and Issues going to this 16.0.1patch release
with “16p1” label?
Martin



On 1. 12. 2022, at 17:21, Eric Barboni 
 wrote:

It will keep jenkins busy and trigger a build per commit and do all
release stack.
Only if a release date for release160 is set in the json, jenkins will
do apidoc only.


Using delivery may be more Jenkins friendly but I don't think it's a human :p.

Eric


-Message d'origine-
De : Neil C Smith  
Envoyé : jeudi 1 décembre 2022 14:52
À : dev@netbeans.apache.org
Objet : Re: [DISCUSSION] Gradle Patch Release for NetBeans 16

On Mon, 28 Nov 2022 at 15:55, Neil C Smith 
 wrote:

On Mon, 28 Nov 2022 at 15:43, László Kishalmi
  wrote:

release161 branch has been removed, PR-s have been re-targeted to
release160.

Great, thanks!  I'm just waiting on votes for rest of additional
binaries to start and I'll close the main vote.  Want to make sure
everything is OK before we merge anything else into the branch.

OK, everything done that needs to be done, so release160 can be
considered open again for merging.

However, I wonder whether we should have a transient branch like
delivery (now deleted) for merging into?  Merges into release***
branches trigger a lot of things.  Eric?

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://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/NETBEANS/Mailing*lists__;Kw!!ACWV5N9M2RV99hQ!IlQ-QlflBngiqiJ-XrDNRp8DGqUnn5Sje469nldr9SZqZxx_bezC8Mq8hTr8TmvWQ0jAtg5rxPxLEVA$





-
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://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/NETBEANS/Mailing*lists__;Kw!!ACWV5N9M2RV99hQ!IlQ-QlflBngiqiJ-XrDNRp8DGqUnn5Sje469nldr9SZqZxx_bezC8Mq8hTr8TmvWQ0jAtg5rxPxLEVA$


 -
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
<https://cwiki.apache.or

Re: [DISCUSSION] Gradle Patch Release for NetBeans 16

[László Kishalmi]

Dear all,

release161 branch has been removed, PR-s have been re-targeted to
release160.

We had as far as I remember 3 update releases for 12 LTS. Out of the 3 one
was released with maven artifacts due to some issues with the original
RELEASE120.


On Mon, Nov 28, 2022 at 5:57 AM Eric Barboni  wrote:

> Hi,
>  Sorry for the disabled jobs. Was not intended. Thought it was because too
> many scan last week.
>
> If we can assume that release160 is ok then you have to check for
>
> https://github.com/apache/netbeans-jenkins-lib/blob/master/meta/netbeansrelease.json
> section release160
> and a adapt to add the new commit hash (should be a tag ) (with name u1 )
> and maven version "mavenversion": "RELEASE160-u1" if a new maven is needed,
> vsixVersion if needed
> build job build the last artefacts but the RM can choose to not call a
> vote on them
>
> For the BOM approach , could be nice but I guess we should use the apache
> groupId, (org.apache.netbeans) otherwise we will have our RELEASE* in the
> path to get a proper last version.
>
> Best Regards
> Eric
>
> -Message d'origine-
> De : Neil C Smith 
> Envoyé : lundi 28 novembre 2022 12:26
> À : Michael Bien 
> Cc : dev@netbeans.apache.org
> Objet : Re: [DISCUSSION] Gradle Patch Release for NetBeans 16
>
> On Mon, 28 Nov 2022 at 10:22, Michael Bien  wrote:
> >
> > On 28.11.22 10:16, Neil C Smith wrote:
> > > On Mon, 28 Nov 2022 at 01:47, Michael Bien  wrote:
> > >> I think I like this approach. Just to be sure I understand: this
> > >> also means there will be no RELEASE161 artifacts in maven-central?
> > >> The only binaries of this release are the updated gradle modules in
> > >> the update center?
> > > I can't say I "like" the approach. :-)  It's the one we have, and
> > > it's a bit of a pain, which is why we've not done it very often!
> >
> > Yeah I can see that. I just think it is good to have a
> > more-lightweight way of releasing a patch if there is the need.
>
> If you think my comment was based on it being too lightweight, you've
> misunderstood what I meant!  The need to manually splice two update
> catalogs, one for testing and voting, then the main one for releasing, is a
> pain.
>
> At least we don't have to JAR sign the NBMs any more!  But yes, practice,
> documenting, and (ideally) some automation would be good.
> particularly if we need to ship high priority updates.
>
> > Eric knows since he told me how to filter the versions you see on the
> > new NB application wizard. There is also a 120-1 btw ;)
>
> That was for a different reason, I believe.  Looks like the u1 was
> requested by Jaroslav -
> https://lists.apache.org/thread/pn9w856x14gqjj4dm9949sgh5vjnod5n
> Discussion of BOM there too.
>
> Another old discussion on update process which might be of interest (also
> bit on BOM) -
> https://lists.apache.org/thread/ysvpkxnnjp22rdv040msvh4o14xn2lds
>
> > There is probably only one u1 since there was only one update to the
> > LTS release, right?
>
> There were two.  There was also an 11.2-u1 which didn't get a Maven
> update.  There were earlier ones too, but not listed in
> netbeansrelease.json as the build process changed with 11.2, which also
> changed the patch release process to that outlined in the above threads.
> Not that we've done that for a while.  And it also appears that I said the
> splicing of the catalog is "not too much work" - I may have changed my
> mind! :-)
>
> > I bet you are already thinking about how to preload the update in your
> > codelerity NB bundles :)
>
> Not unless we decide to release an updated Apache NetBeans binary zip.
> Our installers will always use the contents of the latest binary zip
> release, and you can do a binary comparison of the contents (a deliberate
> design decision).
>
> 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: [DISCUSSION] Gradle Patch Release for NetBeans 16

[László Kishalmi]

Yes, exactly.

On Sun, Nov 27, 2022, 17:47 Michael Bien  wrote:

> On 28.11.22 00:25, Laszlo Kishalmi wrote:
> > Dear all,
> >
> > This is a kind of notice / discussion.
> >
> > Frequent visitors of GitHub might notice, that I've created a new
> > Milestone NB16u1. There are a handful of important fixes in our Gradle
> > Support that would improve the Gradle/JDK compatibility. I think those
> > are important, as some of them are fixing regressions.
> >
> > It's a bit unfortunate that these fixes have arrived late of our NB16
> > release phase. They could be annoying, but I would not stop the
> > release train on them. So I've decided to step up and create an
> > unusual patch release for NB16. I would like it to keep this update
> > release low profile, so we could deliver it ASAP.
> >
> > Some things to know:
> >
> >  * Created a branch for this named: release161
> >  * The milestone is NB16u1
> >  * I'm going to create PR-s against the new branch, by cherry-picking
> >PR-s landed on master.
> >  * Once done, there would be (hopefully) one vote round on the whole
> >source release zip.
> >  * NB16u1 will be delivered trough our Update Center. (Of course, the
> >zip source distribution would be available, but the convenience
> >binary would be just the nbm package)
> >  * I would steer this small update release as an RM, if there would be
> >no objection.
> >
> > Current PR candidates to be included in NB16u1:
> >
> >  * https://github.com/apache/netbeans/pull/5014
> >  * https://github.com/apache/netbeans/pull/4995
> >  * https://github.com/apache/netbeans/pull/4984
> >  * https://github.com/apache/netbeans/pull/4985
> >
> > Also I hope that there would be a fix for this as well:
> >
> > https://github.com/apache/netbeans/issues/5015
> >
> >
> > As usual feedback is welcome!
>
> I think I like this approach. Just to be sure I understand: this also
> means there will be no RELEASE161 artifacts in maven-central? The only
> binaries of this release are the updated gradle modules in the update
> center?
>
> -mbien
>
> >
> >
> > --
> >
> > Laszlo Kishalmi
> >
>
>

Re: [VOTING] Change dev@apache.netbeans to be DMARC/DKIM compliant?

[László Kishalmi]

+1

On Fri, Nov 4, 2022 at 8:06 AM Martin Balin  wrote:

> Hi,
> Recently several of us working on NetBeans were affected by strict
> implementation of DMARC/DKIM on our company server. See
> https://issues.apache.org/jira/browse/INFRA-23780 <
> https://issues.apache.org/jira/browse/INFRA-23780> where I described the
> problem.
> Basically when I sent email from my company email it will be delivered to
> you, but I will not see it in my Inbox as our server will throw it away due
> to "Header From” is original sender which not corresponding to sending
> email server - ASF one.
> I’m not an expert in this area so pardon my simplistic description.
>
> ASF Infra can change the mailing list settings to
> 1. headers will be as suggested and compliant with DMARC. Likely more
> servers will start to enforce it.
> 2. our list to be set as reply-to mailing lists.
>
> ASF Infra expects approval by NetBeans PMC. I don’t feel fully comfortable
> to decide by myself so I’m putting it here for voting.
>
> Please vote in 72 hours as usual.
> This can be turned to discussion if controversial…
>
> Thank you,
> Martin
> PS. I’ve already setup my email to send as @apache.org :-)
>
>

Re: Need an email with @apache.org

[László Kishalmi]

Welcome!

It works the other way around. You need to contribute first. Then you need
to contribute more, get recognized. When recognized you'd be invited as a
commiter to the project. That's the point you can get an apache.org email.

On Fri, Oct 14, 2022, 13:26 Darwin Te  wrote:

> Hi NetBeans Team,
>
> I would like to contribute and need an email @apache.org format as
> invitation.
>
> Let me know my next steps.
>
> Thanks.
>
> Best regards,
>
> Darwin
>
>

Re: Gradle: how to get IDE pickup source from open project

[László Kishalmi]

Well, it seems imported build tasks are handled a bit differently. or the
jvi-cmd:run task is not a JavaExec task.

Then I'd just create a run (JavaExec) task in your build configured the
same way (classpath, main class etc) as it is in jvi-cmd:run

BTW go you have this stuff on GitHub or somewhere public, so I can have a
glimpse? Might be able to file a PR for you.

On Fri, Sep 23, 2022 at 9:31 AM Ernie Rael  wrote:

> On 9/22/22 10:07 PM, Laszlo Kishalmi wrote:
> > Well, if I see well, you try to bring the jvi-cmd:run task down to the
> > project level by defining a task that depends on that.
> >
> > The defined run task would be a DefaultTask, so it is not taking the
> > --debug-jvm argument.
> >
> > Here instead of defining a new run task, I'd configure the ide's run
> > and debug action to use :jvi-cmd:run  or (jvi-cmd:run I'm not sure
> > that the first : is needed) instead of run.
>
> Haven't been able to get debug action to work
>
> Doing
>
> ConfiguredAction: debug, Arguments: :jvi:jvi-cmd:run
>
> And clicking debug runs the command, but no debugger. Change it to
>
> Arguments: :jvi:jvi-cmd:run --debug-jvm
>
> But this hangs. With a different project, with unmodified actions,
> clicking debug shows
>
> cd /src/jvi-dev/jvi/jvi-cmd; ../gradlew --configure-on-demand -x
> check run --debug-jvm
>
> Tried
>
> Arguments: -x check :jvi:jvi-cmd:run --debug-jvm
>
> which fails with "Task 'check' not found in root project 'jvi-ide'.".
> Tried a couple "Hail Mary"s with
>
> Arguments: -x :jvi:jvi-cmd:check :jvi:jvi-cmd:run --debug-jvm
> Arguments: -x :jvi:check :jvi:jvi-cmd:run --debug-jvm
>
> The first doesn't get an error, but hangs just the same. The second
> doesn't find check in jvi.
>
> I thought about running the debugger from the 'buildInclude' project
> directly, but I suspect in a more general case the dependencies would be
> wrong.
>
> -ernie
>
> >
> > On 9/22/22 19:37, Ernie Rael wrote:
> >> On 9/22/22 9:15 AM, László Kishalmi wrote:
> >>> You may find reading this one useful:
> >>> https://docs.gradle.org/current/userguide/composite_builds.html
> >>>
> >> Thanks, this looks promising. I started, only for one project, with
> >> settings.gradle
> >>
> >>rootProject.name = 'jvi-ide'
> >>
> >>includeBuild '/src/jvi-dev/jvi'
> >>
> >> Mixed in some build.gradle
> >>
> >>def jvi_proj = [ ':jvi-core', ':jvi-swing', ':jvi-cmd' ]
> >>
> >>void deps(Task t, String proj, List subprojs, String subt) {
> >> for(sp in subprojs) {
> >> t.dependsOn gradle.includedBuild(proj).task(sp + subt)
> >> }
> >>}
> >>
> >>tasks.register('clean') { task ->
> >> deps(task, 'jvi', jvi_proj, ':clean')
> >>}
> >>...
> >>tasks.register('run') {
> >> dependsOn gradle.includedBuild('jvi').task(':jvi-cmd:run')
> >>}
> >>
> >> I thought it was weird that I had to enumerate the sub-projects, but
> >> some think I'm weird.
> >>
> >> Opening this project in ide I can build, clean, Use the GREEN button
> >> to run the project, but the DEBUG button fails. Suggestions? IDE output:
> >>
> >> cd /src/jvi-dev/jvi-ide; ./gradlew --configure-on-demand run
> >> ...
> >> > Configure project :jvi:jvi-swing
> >> namedservicesMerge-1: project ':jvi:jvi-swing'
> >> 'jVi/init/com.raelity.jvi.ViInitialization'
> >> Configuration on demand is an incubating feature.
> >>
> >> > Task :jvi:jvi-core:compileJava UP-TO-DATE
> >> ...
> >>
> >> > Task :jvi:jvi-cmd:run
> >>
> >> ==
> >> cd /src/jvi-dev/jvi-ide; ./gradlew --configure-on-demand run --debug-jvm
> >> ...
> >> > Configure project :jvi:jvi-swing
> >> namedservicesMerge-1: project ':jvi:jvi-swing'
> >> 'jVi/init/com.raelity.jvi.ViInitialization'
> >> Configuration on demand is an incubating feature.
> >>
> >> FAILURE: Build failed with an exception.
> >>
> >> * What went wrong:
> >> Problem configuring task :run from command line.
> >> > Unknown command-line option '--debug-jvm'.
> >>
> >
> > -
> > 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: how to get IDE pickup source from open project

[László Kishalmi]

You may find reading this one useful:
https://docs.gradle.org/current/userguide/composite_builds.html

On Thu, Sep 22, 2022 at 7:43 AM Ernie Rael  wrote:

> Thanks László,
>
> Since I got thing back in sync, have not seen the problem. I tried what
> I think were similar steps, it /did not reproduce/. Did not get into a
> situation where it seemed like I needed to nuke the on disk cache.
> Here's the steps, I see some things I'm not sure about, clarification on
> expectations would be great.
>
> Given two separate projects: app, lib. Where lib publishes to maven
> repository
>
>  1. put method "void XXX(String)" in lib
> Publish lib local from console, access it from lib in IDE, build ok.
>  2. modify lib sig to "void XXX(int)", publish lib local to new version
> from console
>  3. In app's buildSrc to reference new version. (but don't fix call to
> XXX new arg type)
> IDE shows no error, build app from IDE, build gets error
>  4. build lib in IDE, IDE still shows no error in app
>  5. change sig in app to call "XXX(int)"
> IDE shows error, but IDE builds with no error
>  6. Close IDE, flush IDE cache, restart IDE
> IDE shows no error, seems like flush cleared up problem in IDE cache
>
> So I could not reproduce a problem that required gradle cache cleanup.
> (though it seems I had reproducible steps that required IDE flush) I
> tried similar steps again, but instead in step 2, I used IDE to run
> action from navigator to publish lib to local maven, and IDE picked up
> the change and were consistent. So it seems like running stuff from
> console, isn't always picked up from the IDE. Was I hallucinating?
>
> Good to know about "Reload" project. If I see something peculiar, I can
> try that.
>
> I will stop using SNAPSHOTS, thanks. I guess the key is to turn off
> mavenLocal() to verify that I need to publish something :-)
>
> -ernie
>
> On 9/20/22 10:53 PM, László Kishalmi wrote:
> > I would say the on-disk cache is pretty stable by now, probably we
> > should remove that from being experimental.
> > I would check the project properties, the Sources section, and the
> > compile classpath section if that looks right.
> > You could check if reloading the project (right click on the project
> > node, the Reload) would help. That one would clear the cache and get a
> > fresh information from Gradle.
> > So, if that's not helping then, there is something else that the IDE
> > does not pick up.
> >
> > If the project could be disclosed, I could take a look.
> >
> > Hint: One of the bad things Maven introduced were the SNAPSHOT
> > versions. They created them as in the early days (probably pre 3.0)
> > the only way to reference dependencies between entities (sub projects
> > in Gradle term) of in a multi-pom projects was through the deployed
> > SNAPSHOT version of the library in the Local Maven repository. That's
> > gone now. SNAPSHOT versions should be avoided.
> >
> > On Tue, Sep 20, 2022 at 6:00 PM Ernie Rael  wrote:
> >
> > (Apologies if you see a duplicate)
> >
> > Using NB-15, jdk-11
> >
> > I have a library on MavenCentral (published from a gradle
> > project), that
> > I use in another project. I'm creating new version of that
> > library. I'm
> > into problems and peculiarities.
> >
> > 1. NetBeans remembered some method signatures that were not valid
> > 2. In debugger opened source from snapshot jar file, rather than from
> > open file from open project
> >
> > 1 seemed like a clear error; found a dance that got rid of the
> > problem,
> > see below.
> >
> > If 2 is correct, how can I set things up during dev/debug to get
> > around it?
> >
> > ** Some notes on 1. **
> >
> > I've created a v1.1-SNAPSHOT and publishToMavenLocal.
> >
> > I've got the following in BuildSrc in a project that uses the
> snapshot
> >
> > repositories {
> >  mavenCentral()
> >  mavenLocal()
> >  // maven { url
> > 'https://oss.sonatype.org/content/repositories/snapshots/' }
> > }
> >
> > I use mavenLocal to access the snapshot..
> >
> > In NetBeans, working on a project that uses the snapshot, although
> > I can
> > do a clean build, I had error indicators referring to some signatures
> > that are not valid in the snapshot. I tried closing NetBeans and
> >   

Re: Using the same userdir from previous release

[László Kishalmi]

This is what's Snap uses to fix old user dirs with external nbjavac
https://github.com/apache/netbeans-tools/blob/master/snap-packages/launchers/nbjavac-cleanup

On Fri, Sep 16, 2022 at 9:13 AM Michael Bien  wrote:

> On 16.09.22 17:19, Ernie Rael wrote:
> > On 9/15/22 10:44 PM, Michael Bien wrote:
> >> On 16.09.22 07:31, Laszlo Kishalmi wrote:
> >>> I started to reply on this, but not sure if I really pressed the
> >>> send button, and I do not see my reply. So I'm sorry if I'm
> >>> repeating myself.
> >>>
> >>> So the Snap distribution does exactly the same (Snap provides the
> >>> infrastructure for that). Whenever NetBeans updated the user dir
> >>> gets copied from the current version to the new version and an empty
> >>> cache dir is created.
> >
> > Good to know, I'll stay with copying and keep my eyes open for
> > non-compatible changes, or at least the squawking if one happens.
> >
> > The huge advantage of copying the userdir is not having to install
> > plugins again.
> >
> > BTW, my plugin has a lot of stuff in preferences and it defines
> > include/exclude in layers so it works well with the "Tools > Options >
> > Import/Export" buttons. But since it is not in the release compiled
> > layers...
>
> yeah this area needs some improvements. I see periodically issues when
> users import plugins from old NB versions (e.g 11) and break things.
> (its probably nb-javac, since it changed namespace at some point which
> allows it to be installed twice, resetting the config fixes it).
>
> So there needs to be some cap. e.g nb_version - 2. But first of all, the
> plugin portal probably needs to be fixed (i believe someone is working
> on it), so that it isn't empty on new releases when most people update.
>
> The import/export module config might be stored somewhere in the module.
> If it is, it could automatically migrate the stable config on plugin
> import from an older config. Since you say it works with the explicit
> import/export via options but not with the auto import on first start?
> If true, this is either a bug or a missing feature since I don't see why
> it would behave differently :)
>
> best regards,
>
> michael
>
> >
> > Thanks for the info,
> > -ernie
> >
> >>> It is relatively safe to do that in the last few years, no one
> >>> really touched the config settings part.
> >>>
> >>> The import from previous version does the same, however it has some
> >>> rules importing from NetBeans 5.5, 6.0, pretty old versions
> >>> (probably we can remove that code).
> >>
> >> it should use the include/exclude list in etc/netbeans.import, which
> >> is generated by the layer at build time ("OptionsExport" folder).
> >>
> >> I didn't know that either but I figured this out when I added the
> >> migration of the jackpot rule files so I didn't have to copy them
> >> manually.
> >>
> >> So you can influence what is migrated simply by editing this file
> >> before first launch :)
> >>
> >> -mbien
> >>
> >>>
> >>> On 9/15/22 10:34, Ernie Rael wrote:
>  On 9/14/22 5:55 PM, Michael Bien wrote:
> >
> > On 10.09.22 01:53, Ernie Rael wrote:
> >> With release 15 I did something like
> >>
> >>mkdir 15
> >>cp -a 14/userdir 15/userdir
> >>
> >> Then start NetBeans-15 using 15/userdir and a fresh cachedir.
> >>
> >> Simpler than import settings. Is there any problem/downside doing
> >> this?
> >
> > the downside is that NB doesn't expect this to happen. So it might
> > work, or it might break (something). Since the config format might
> > have changed somewhere in between versions.
> 
>  Yeah. And if it mostly works, that's the worst.
> 
> >
> > If you would just start NB 15 normally without a 15 folder, it
> > will ask you to migrate some of the config of 14.
> 
>  I've had a non-standard setup/directories since windows days; can't
>  remember why exactly; maybe just cause I thought it sucked on
>  windows. Kept it when I moved to linux last year. Have my own
>  startup scripts.
> 
>  I looked for  a --initial-startup-import-from option, couldn't find
>  it :-)
> 
>  Is it the same (or close enough) to use "Tools > Options > Import",
>  and grab everything from the prev userdir on first startup? Don't
>  think it is, but it might be after installing favorite plugins, so
>  what to import is defined.
> 
>  Making a symlink got it too work. "cd ~/.netbeans; ln -s
>  ~/.nb/.../prevudir 15" works. Something to add to my install new NB
>  process. This seems to pull everything from Preferences, even if
>  the plugins aren't installed yet.
> 
>  Thanks for waving me off use prev udir,
>  -ernie
> 
> >
> > It will import settings like project groups, platforms, editor
> > config (even custom jackpot rules now), theme etc. but window
> > setup for example is reset. Thats usually how I upgrade - setting
> > up the windows 

Re: Sudden File Lock Freeze

[László Kishalmi]

Or you can try to attach a VisualVM to the NetBeans process, to see what
the IDE is doing.

On Tue, Sep 13, 2022 at 9:34 AM Ernie Rael  wrote:

> There a program that will tell you what windows processes have a given
> file open, maybe other info about the file. That might be informative.
>
> -ernie
>
> (I'm rushed, can't look for it now)
>
>
> On 9/13/22 7:20 AM, Ömer Halit Çizmeci wrote:
> > Well. It is still a possibility but I doubt that because it's a high end
> > new PC. If that ever happens again, do you need me to do anything
> > specifically? Just keep in mind that NetBeans does not respond at all.
> >
> > On Tue, Sep 13, 2022, 5:16 PM Eirik Bakke  wrote:
> >
> >> One possibility--perhaps less likely than a bug in NetBeans, but still
> >> worth considering--is a failing hard drive or SSD drive. It might be a
> good
> >> time to take a backup of your files, just in case.
> >>
> >> -- Eirik
> >>
> >> -Original Message-
> >> From: Ömer Halit Çizmeci 
> >> Sent: Tuesday, September 13, 2022 2:50 AM
> >> To: dev@netbeans.apache.org
> >> Subject: Re: Sudden File Lock Freeze
> >>
> >> I only encountered this while editing .java files but I am not sure if
> it
> >> is file type specific. It is part of a Java Web Application project file
> >> and I can guarantee that the file is not opened in any other
> application. I
> >> don't have any antivirus program other than Windows Defender and I don't
> >> have a virus on my computer.
> >>
> >> On Tue, Sep 13, 2022, 4:58 AM Laszlo Kishalmi <
> laszlo.kisha...@gmail.com>
> >> wrote:
> >>
> >>> One of the most important information is missing.
> >>>
> >>> What type of file are you editing?
> >>>
> >>> On 9/12/22 17:01, Ömer Halit Çizmeci wrote:
>  Hi,
> 
>  I have been having this problem I think since NB13 and it occurs in
>  NB14 and NB15. The application suddenly freezes entirely with no
>  response at
> >>> all
>  when I hit CTRL+S to save a file. There is no pattern I could figure
>  out but when this happens, it is extremely hard to revert it back to
> >> normal.
>  Restarting NetBeans does not help. Restarting my PC does not help.
> >>> Whenever
>  I save on that specific file, NetBeans freezes immediately and the
>  only
> >>> way
>  is to force close in task manager.
> 
>  After this incident repeat so many times, I had to look for a
> >> workaround.
>  The only way I was able to resume NetBeans without having to force
>  close was to navigate to the file via file explorer and rename that
>  specific file. Then NB would pop-up the file modified outside of NB
>  and ask if I want to reload. After this point, NB continues to run
>  as normal but if I hit CTRL+S again on that file, NB will freeze.
>  And restarting Windows or NetBeans does not help.
> 
>  After a long time of investigating, I was able to find a way to fix
>  it
> >>> for
>  that moment. I'd open that specific file in Notepad and make a
>  slight modification and save it. Then NetBeans is able to save on
>  that file and runs normally until this random bug appears. It is
>  like the file is
> >>> locked
>  by another process and NetBeans cannot get hold of that file and
> >> freezes.
>  This happens randomly with random files.
> 
>  This happens in Windows 10 and Windows 11 using NB15 with Java 17.
> 
>  What else should I provide to contribute to this?
> 
> >>> -
> >>> 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

[László Kishalmi]

If someone is more brave can add the following option to NetBeans right now:
That would turn off the NetBeans Clipboard hacks, including the part of the
code mentioned in my PR.

-J-Dnetbeans.slow.system.clipboard.hack=false

On Wed, Aug 31, 2022 at 1:55 PM Scott Palmer  wrote:

> 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, N

Re: Copy Paste still an issue

[László Kishalmi]

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

[László Kishalmi]

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 
> 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: committer/pmc opinions needed for PR which is in limbo for NB 15 inclusion

[László Kishalmi]

I was about to check the PR, could not find the time for that though.

I'm sorry

On Thu, Aug 18, 2022 at 7:02 AM Michael Bien  wrote:

> On 18.08.22 12:09, Neil C Smith wrote:
> > On Mon, 15 Aug 2022 at 14:21, Michael Bien  wrote:
> >> So please review for correctness first, and if you review mention in the
> >> comment if you want to see this PR for 15 or 16.
> > This PR is now in rc4.
> >
> >  From a releases perspective, can I add that we really need correctness
> > and suitability of base branch (eg. delivery) to be reviewed together.
> > Any reviewer can, and should if necessary, veto a merge to delivery
> > even if they're 100% happy with the code being merged to master.
> >
> > While I somewhat shared Matthias' reservations about merging for rc4,
> > as I said on the PR it would be merged if no-one else vetoed.  It's
> > not the job of people doing release builds to "clear" things.
>
> agreed. That was essentially the reason for the mail, to generate a
> clear NO or YES for NB15 integration once more reviews are available.
> Unfortunately nobody said anything :(
>
> (in my mind a review approval with the comment "for NB16" would veto
> NB15 merge, a change request would "veto" the entire PR etc)
>
> -mbien
>
> > 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?

[László Kishalmi]

I agree. I've only done the minimum between two meetings. Feel free to
create a more complete one.

On Thu, Aug 11, 2022 at 10:06 AM Scott Palmer  wrote:

> 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 <
> laszlo.kisha...@gmail.com>
> > 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: API snapshot review for NetBeans 15 - possible issue?

[László Kishalmi]

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
>>
>>
>>
>>

Re: API snapshot review for NetBeans 15 - possible issue?

[László Kishalmi]

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
>
>
>
>

Re: Release end

[László Kishalmi]

That actually never stopped. At the moment there are 69 Pars merged for NB15

On Thu, Jun 23, 2022, 04:37 Łukasz Bownik  wrote:

> When will you guys start merging PRs again?
>  No pressure, just asking.
>

Re: NetBeans 13 Crashing

[László Kishalmi]

Start from command line, see the console logs. Delete the user and cache
dirs.

On Sun, Apr 3, 2022, 06:06 Eric Bresie  wrote:

> Asking the obvious question….Is Java installed?
>
> Eric
>
> On Sat, Apr 2, 2022 at 1:13 PM Brandon M. F  wrote:
>
> > Hello!
> >
> > I attempted to download NetBeans 13 last night on Windows 10, and it was
> > successfully downloaded (from what I could tell), after the program
> loaded
> > the first time, it crashed, and now all I get is the "NetBeans 13 loading
> > modules" screen before it crashes again and does not display the GUI.
> >
> > Any suggestions on what to do?
> >
> > I have already attempted to uninstall and reinstall, but to no success.
> >
> --
> Eric Bresie
> ebre...@gmail.com
>

Re: Debugging Broken in NetBeans master - PLEASE DO NOT MERGE FURTHER CHANGES

[László Kishalmi]

Is master open for merges after https://github.com/apache/netbeans/pull/3244
?

On Tue, Oct 12, 2021 at 10:22 PM Jaroslav Tulach 
wrote:

> > PLEASE DO NOT MERGE FURTHER CHANGES
>
> I can see that the revert PR-3181 wasn't approved by Martin Entlicher and
> that
> his another PR-3204 hasn't been reviewed and approved by you.
>
> Looks like serious communication breakdown. Thanks for letting us know
> before
> starting another round of reverts.
>
> > What to do about this? The best case scenario:
>
> Treat this as a bug, talk to each other, make debugger work in 12.6 and
> let
> make the debugger work fast.
> -jt
>
> > Hi,
> >
> > I want to raise awareness of the broken state of debugging in NetBeans
> > IDE. I raise it here and now, because reverting the initial changes
> > alone does not help anymore.
> >
> > The problem starts with this PR:
> >
> > https://github.com/apache/netbeans/pull/3158
> >
> > that was reverted via
> >
> > https://github.com/apache/netbeans/pull/3181
> >
> > and resubmitted as
> >
> > https://github.com/apache/netbeans/pull/3204
> >
> > After the merge of PR3204 it looked ok, but I did not test with
> > "Suspend all threads" and this is now totally broken in NetBeans
> > master.
> >
> > See the final comment in PR 3204 for a description of the issue.
> >
> > The big question is: What to do about this? A trivial revert fails as
> > there are conflicting changes in the area.
> >
> > The best case scenario: Debugging will be fixed and be stable again as
> > it was in the past.
> >
> > Worst case scenario: We revert all changes, that touch the JPDA code
> > and everything, that causes conflicts.
> >
> > I would prefer the best case scenario.
> >
> > 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: [LAZY CONSENSUS] Drop support for building (and officially running) on JDK 8 after 12.6 [1 of 2]

[László Kishalmi]

Rather conservative, but at least moving forward: +1

On Thu, Oct 7, 2021 at 6:05 AM Neil C Smith  wrote:

> As we move onwards to Apache NetBeans 12.6 there are a number of
> points that still need resolution before the freeze date on Oct 15th -
> some mentioned in the previous lazy consensus thread on releases in
> January [1].
>
> This is thread 1 of 2, and covers elements discussed on moving to
> requiring JDK 11 for building NetBeans and the use of modules that
> require JDK 11+ at runtime. [2] Hopefully this addresses concerns
> raised there.
>
> We'd like to propose the following -
>
> * Apache NetBeans 12.6 will be the last release that can be built
> using JDK 8. The following release will require JDK 11 to build.
> * All Apache NetBeans 12.6 convenience binaries will aim to be built
> with JDK 11 (let's make sure we're ready for it!)
> * Apache NetBeans 12.6 will be the last release where the IDE as a
> whole "officially" supports running on JDK 8. We already say we
> require JDK 9+ for the IDE, with limited support for JDK 8. Let's be
> more explicit.
> * At least while certain dependent projects, such as VSNetBeans,
> require JDK 8 support, most of the IDE will be built to be compatible
> with JDK 8. The IDE should therefore continue to run on JDK 8, but
> users should expect features may "drop out" over future releases.
> * From point of 12.6 branching, modules may be added or upgraded to
> require JDK 11 (using OpenIDE-Module-Java-Dependencies: Java > 11). No
> module will do so without good reason, as an alternative
> implementation where possible, with proper review in place, and
> without compromising selected dependent projects.
> * Automated testing on JDK 8 will remain as is where required and
> infrastructure supports it. User testing of the IDE on JDK 8 shouldn't
> be expected.
>
> This thread is open for 72hrs under lazy consensus [3]. I'd summarize
> and expand that to don't make extra work for other people. ie. -1 any
> point here if you are offering an alternative that you can help
> implement OR if any point will cause problems / extra work for you.
>
> Thanks,
>
> Neil
> on behalf of release team
>
> [1]:
> https://lists.apache.org/thread.html/r08e565beb4027d75cf21cd5385e16001d21b778af2113ed7d7b0de4a%40%3Cdev.netbeans.apache.org%3E
> [2]:
> https://lists.apache.org/thread.html/ra00056e722c984c7335035c817fee8a925291d11be83330e27254c8c%40%3Cdev.netbeans.apache.org%3E
> [3]: https://community.apache.org/committers/lazyConsensus.html /
> https://community.apache.org/committers/consensusBuilding.html
>
> -
> 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: Apache JIRA vs GitHub issues / discussions

[László Kishalmi]

Well, first of all, I'm fine with whatever tool we use for tracking issues.

Though I think first we shall show that we could do manage those issues
that are reported. Close those which are no longer valid, old, not enough
info whatever. Respond on new ones, etc. Once we can do that. We can
discuss on tools. Otherwise we just let the crap flowing to a new place,
while confusing users.



On Sun, Sep 26, 2021, 09:10 Eric Bresie  wrote:

> A long one coming I know but hear me out please
>
> I know everyone involved here has their day jobs and does this mainly as
> an advocate for the product, as a hobby, or supporting their own interest
> so I think it's important to focus on how to make this easier for those
> involved.
>
> Changing from JIRA to Github would only risk further confusing things as
> happens when transitioning from bugzilla (https://bz.apache.org/netbeans/) to
> jira.
>
> Discussions can happen in JIRA tickets just as easily as in GitHub and
> PRs.  Having the PR owner drive the "discussion" is the same as a ticket
> owner driving the ticket discussion.  PR discussions seem to me to be
> focused on the changes made in the PR, not necessarily the higher level
> discussions for possible solutions of the ticket.
>
> The reason there are so many tickets is no one or no group has taken
> ownership of it (i.e. no change control).  I still think some form of
> "change management team" or "JIRA Triage" team could help here.  Is it
> possible to have a Slack channel for CCB activities or a mailing list?
>
> Or even wilder ideas, since less emphasis has been given to LTR and Netcat
> activities, maybe the Netcat list should be repurposed for some of this
> change control activity.  If a given test case is relevant to a given
> component and functionality, it can be linked up with that and then when
> run if it is verified to not be an issue then close it.
>
> Seems to mean like there isn't a clear process of how JIRA usage is
> expected to be used.  If there is one, where is it (confluence, Wiki,
> etc.)?
>
> JIRA / Change Process seems like :
>
> (1) New ticket is raised by someone
> (2) (Hopefully) Details on how to reproduce and verify it's closed are
> clearly defined
> (3) Ticket is analyzed (i.e. impacted components, priority
> (4) Someone is assigned, volunteers, or takes ownership of the ticket
> (5) Someone comes up with a possible fix
> (6) Someone associated PR to fix
> (7) Testers (including [1] capability subject matter expert, and [2] the
> author of the ticket) test the fix and confirm/reject the change
> (8) If accepted then the ticket is ready to transition to "integration
> gate" [i.e. can be labels or tagged for a milestones for an upcoming
> release [maybe "candidate" of some type).
> (9) Release team can review candidates based on applicable labeled or
> milestone an evaluate for merging
> (10) Merged into a release candidate build
> (11) Beta/Release Candidate/Final Build released for community review
> (12) Team accepts based on vote
> (13) Release is released
> (14) All tickets associated with a given release are "Closed"
> (15) If an issue is later found to not have been fixed then either
> "Reopen" the ticket or "Raise a new ticket with more specifics" (goto (1))
>
> There is lots of power in JIRA if it's used. For example
> * Note: I would share these JIRA searches but I don't have the ability to
> "Share" filters so will provide a URL based link instead.
>
> (1) Find tickets created in the last 7 days
> project = NetBeans AND created >= -7d
> 
> * Would propose with tickets like these they could be "triaged" weekly and
> set applicable minimum things (i.e. impacted components,priority, potential
> target releases, complexity, etc.)
>
> (2) Tickets which are not closed yet
> project = NetBeans AND status not in (Closed)
> 
> * Can help identify tickets not in "Closed" even those that have been
> "resolved".
> * Items resolved and in a build if verified should be "Closeable"
>
> (3) Tickets not assigned to anyone
> project = NetBeans AND assignee is EMPTY
> 
> * Helps identify who is not actively working on given tickets
>
> (4) Tickets not tagged to any components
> project = NetBeans AND component is EMPTY
> 
> * Grouping things by components may help potential similar or related
> issues
> * Can group tickets to a given component which can localize issues and
> allow component exports to be more aware of changes and provide oversite or
> input on changes for the given component
> (5) Tickets tagged to a specific component (as an example)
> project = NETBEANS AND component = "pr

Release Apache NetBeans 12.5 Linux Snap Package

[László Kishalmi]

Dear all,

It is just an FYI that the Snap package is available at the latest/edge
channel on https://snapcraft.io/netbeans

It's waiting to be promoted. That usually happens after the announcement of
the release.

--

  Laszlo Kishalmi

Re: System.out.print buffered to Output Window

[László Kishalmi]

For those kind of projects use Ant or Gradle. They do not suffer from this
issue, and probably better suited for small student projects.

On Sat, Aug 28, 2021, 13:16 David Green  wrote:

> Thanks for the reply and insight.
>
> That does work at the command line (as did running it from a jar file).  I
> am seeking to have it work in the NetBeans Output window and I found that
> if I edited the Run (and Run File) Actions in the project properties to use
> "java" instead of "exec", it does work.  It did generate a nbactions.xml
> file that was not there before.
>
> Should this be the default behavior when one generates Java with Maven |
> Java Application?  I am looking for configurations to use with students who
> are learning the language and OO thinking and don't want to add any more
> friction than necessary.
>
> Are there any downsides of making this change?
>
> Dave
>
>
>
>
>
>
>
> On Sat, Aug 28, 2021 at 2:15 PM Vladimir Machat 
> wrote:
>
> > Hi,
> >
> > i believe it's exec:exec maven target problem, because if you run the
> > same code with exec:java it works perfectly, even without the flush()
> >
> > try 'mvn exec:java -Dexec.mainClass=dgreen.printbug.NewMain' from
> > command line
> >
> > On 28/08/2021 18:54, David Green wrote:
> > > In NetBeans 12.4 and verified to also behave this way on NetBeans
> > > 12.5-beta2, System.out.print is buffered such that it does not show up
> in
> > > the NetBeans Output window until a System.out.println (or probably
> things
> > > like program end, and some buffer full scenario).
> > >
> > > Using JDK 15 and a Maven Project.  I am using macOS but my students who
> > hit
> > > this problem are using Windows.
> > >
> > > Example code:
> > >
> > > package dgreen.printbug;
> > >
> > > import java.util.Scanner;
> > >
> > > /**
> > >   * Demo program showing that System.out.print's are not pushed to
> output
> > > window until a
> > >   * System.out.println
> > >   */
> > > public class NewMain {
> > >
> > >/** @param args the command line arguments */
> > >public static void main(String[] args) {
> > >  Scanner sc = new Scanner(System.in);
> > >  System.out.print("Enter your name: ");
> > >  System.out.flush(); // should not be necessary but does not work
> > either
> > >  String name = sc.nextLine();
> > >  System.out.println("Hi " + name);
> > >}
> > > }
> > >
> > > —-
> > > Running it after Clean & Build (or before)
> > >
> > > --- exec-maven-plugin:3.0.0:exec (default-cli) @ printbug ---
> > > dave
> > > Enter your name: Hi dave
> > >
> 
> > > BUILD SUCCESS
> > >
> > > where "dave" was typed in without the benefit of seeing the prompt.
> > >
> > > This works fine when run from true command line either inside a
> NetBeans
> > > Terminal Window or the real command line.
> > >
> > > In Jira as https://issues.apache.org/jira/browse/NETBEANS-5961
> > >
> > > Dave
> > >
> >
>

Re: Apache NetBeans 12.2-beta2 will be later today!

[László Kishalmi]

Thanks Eric!

Go for it!

On Fri, Oct 23, 2020, 01:48 Eric Barboni  wrote:

> Hi Laszlo A PR for  that:
>
> https://github.com/apache/netbeans-jenkins-lib/pull/22
>
> I can merge it , but I was waiting in order to not interfer with RM.
>
> Best Regards
>
> Eric
>
> -Message d'origine-
> De : Laszlo Kishalmi 
> Envoyé : vendredi 23 octobre 2020 09:22
> À : Apache NetBeans 
> Objet : Apache NetBeans 12.2-beta2 will be later today!
>
> I'm sorry to inform you, that Apache NetBeans 12.2-beta2 will be a bit
> late.
>
> The commits and merges went fine both the delivery -> release122 and
> delivery -> master.
>
> Unfortunately Apache infra changed the tool names on Jenkins, so all of
> our TLP build jobs are failing.
>
> Well it just passed midnight here, so I'm going to turn in, but if someone
> in another time zone, can check this that would be awesome!
>
> --
>
>Laszlo Kishalmi
>
>
> -
> 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 Platform modules and JDK 11+ modules

[László Kishalmi]

Where there are similarities, NB modules are dynamic, Java modules are
static, at least as far as I know.

On Thu, Jan 9, 2020, 02:09 Geertjan Wielenga  wrote:

> It is not. Does it need to?
>
> Gj
>
> On Thu, 9 Jan 2020 at 10:06, Jean-Marc Borer  wrote:
>
> > Hi guys,
> >
> > I just had a discussion with colleagues about NB module system. We were
> > wondering how this system is cohabitating with "new" Java module system.
> >
> > Any idea or documentation/article/thread/information?
> >
> > Cheers,
> >
> > JMB
> >
>

Re: Approaching Darkness

[László Kishalmi]

Merged to the master. Happy polishing/theming!

On Sat, Nov 23, 2019, 01:28 Laszlo Kishalmi 
wrote:

> Dear all,
>
> Say hello to our long lost pals Dark Metal and Dark Nimbus Look and
> Feels at: https://github.com/apache/netbeans/pull/1651
>
> (I've seen in its day several people were fond of the Dark Metal LaF, I
> never understood why...)
>
> I also took on Junichi Yamamoto's idea on including FlatLaf as a Look
> and Feel option and kicked some rocks together:
> https://github.com/apache/netbeans/pull/1652
>
> If there is no strong opinion against that I'd merge that code on
> Monday. Let's see what could we do with that as a community (a fitting
> editor color schema is going to be needed as well).
>
>
>
>

Re: Re: Netbean Gradle with Java 13

[László Kishalmi]

Not tested throughosly, but it seems no. The current tooling API though it
is 4.6.2 still works well with newer Gradle versions. Though 11.3 will come
with 6.x Gradle tooling.

On Mon, Oct 21, 2019, 09:02 Eric Bresie  wrote:

> Is that going to require changes to the Netbeans internal Gradle
> functionality
>
> Eric Bresie
> ebre...@gmail.com
>
> On October 19, 2019 at 12:03:05 PM CDT, Laszlo Kishalmi <
> laszlo.kisha...@gmail.com> wrote:
> Well,
>
> Using Java 13 with Gradle in NetBeans is possible, I'm intending to
> create a short video how to set up that. The key point is that you need
> to use Gradle 6.0 development builds which supports Java 13. So the
> quick steps:
>
> 1. Upgrade your wrapper to 6.0 nightly:
> https://gradle.org/release-nightly/ or download it and extract it and
> set up the IDE use that version
>
> 2. Configure JDK 13 in NetBeans and assign that to your project.
>
> That's it.
>
> On 10/19/19 7:23 AM, ebresie...@gmail.com wrote:
>
> Not sure this will be something to watch going forward but on the
> openjfx-Dev mailing list [1], I noticed with Java 13, there was some Gradle
> build issues. Is this likely to impact Gradle builds in Netbeans as well?
>
> [1]
> https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-October/023737.html
>
> Eric Bresie
> ebre...@gmail.com
>
>
> -
> 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: [SNAP] Pinned IDE snap won't start from KDE Plasma's Latte Dock

[László Kishalmi]

Also try to build and install the snap on your machine. Snap checks/filters
the desktop file.

On Tue, Aug 6, 2019, 10:20 Patrik Karlström  wrote:

> And now the PR is ready for a review.
> https://github.com/apache/netbeans/pull/1406
>
> Keeping my fingers crossed that everything works out.
>
> Den tis 6 aug. 2019 kl 08:22 skrev Patrik Karlström :
>
> > I found that the pinned snap won't start from Latte Dock due to a missing
> > line in the desktop file.
> > StartupWMClass=Apache NetBeans 11.1
> >
> > I would like to once and for all do my first contribution with this fix
> in
> > order to learn the process.
> >
> > So, I'll
> > -post on the dev list (done)
> > -create a JIRA ticket that points to the thread on the list
> > -inform on the list about the ticket
> > -create PR by following
> > https://netbeans.apache.org/participate/submit-pr.html
> > -asking for a review
> >
> > Is that all?
> >
>

Re: Java NIO2 based watchers are on master now, please watch the IDE performance!

[László Kishalmi]

NIO2 has no native implementation on MacOS, so we use our own version, so
people using MacOS shall not see a difference.

On Tue, Jul 30, 2019, 17:04 Scott Palmer  wrote:

> For clarification, was macOS already using NIO2 or is it purposefully not
> using NIO2?
>
> Scott
>
> > On Jul 30, 2019, at 4:15 pm, Laszlo Kishalmi 
> wrote:
> >
> > Dear all,
> >
> > I've merged a PR which makes the Java NIO2 file watcher implementation
> default on Windows and Linux. I'd encourage to test the latest development
> builds and even use them for a while, as we would like to be sure that this
> change has no negative side effect, also would like to hear if it has
> positive effects.
> >
> > Unfortunately due to Apache Jenkins overload our latest builds were
> failing on Apache, but hopefully it will be available for test soon.
> >
> > The change is available with the latest snap weekly dev build (which
> passed recently):
> >
> > snap install --channel edge netbeans-dev --classic
> >
> > https://builds.apache.org/job/netbeans-snap-weekly-master/changes
> >
> >
> > Feedback, feedback, feedback, please!
> >
>

Re: JavaFX Wrapper should be updated

[László Kishalmi]

Please touch the NetBeans Code as well, at least in a form of pull request!

On Thu, Jul 18, 2019, 07:32 Zoran Sevarac  wrote:

> Thanks help Neil and Jarda, I've made it working somehow. No worries I wont
> be touching NetBeans code, its for my Platform based app
>
>
> On Wed, Jul 17, 2019 at 10:13 AM Jaroslav Tulach <
> jaroslav.tul...@gmail.com>
> wrote:
>
> > Just make sure you don't break anything on JDK8, JDK9, JDK10, JDK11, ...,
> > etc. FYI:
> >
> >
> http://bits.netbeans.org/dev/javadoc/org-openide-modules/apichanges.html#javafx.lib
> > -jt
> > <
> http://bits.netbeans.org/dev/javadoc/org-openide-modules/apichanges.html#javafx.lib-jt
> >
> >
> >
> > út 16. 7. 2019 v 16:15 odesílatel Geertjan Wielenga  >
> > napsal:
> >
> > > Toni is not using it, see above.
> > >
> > > Gj
> > >
> > > On Tue, Jul 16, 2019 at 4:14 PM Zoran Sevarac 
> wrote:
> > >
> > > > On Tue, Jul 16, 2019 at 9:18 AM Geertjan Wielenga <
> geert...@apache.org
> > >
> > > > wrote:
> > > >
> > > > > The HTML UI API, that is DukeScript, so you should ask Toni if/how
> he
> > > is
> > > > > using that library.
> > > > >
> > > > > No, we are not simply going to remove this or any other library.
> > > > >
> > > >
> > > > It does not work anyway because it has hard coded dependency to jar
> > from
> > > > JDK8.
> > > > @Toni what's your solution? :)
> > > >
> > >
> >
>
>
> --
> Zoran Sevarac, PhD, Associate Professor
> Department of Software Engineering
> University of Belgrade, Faculty of Organisational Sciences
> 
> Deep Netts   Co-founder & CEO  | Oracle
> Groundbreaker Ambassador | Java Champion
> 
> Open source: Neuroph founder, Apache Net
> Beans  contributor
> Homepage: http://www.zoransevarac.com
>

Re: [DISCUSS] import Bugzilla to Jira or Plan to Drop Bugzilla

[László Kishalmi]

+1 for import bugzilla into apache bugzilla and keep it read only. Apache
supports bugzilla, so that should be feasible.

On Sat, Apr 20, 2019, 02:16 Neil C Smith  wrote:

> On Sat, 20 Apr 2019, 02:37 Geertjan Wielenga,  wrote:
>
> > My understanding is Oracle NetBeans bugzilla is being kept in readonly
> > state. That’s how e.g., Reema, is using and needing it.
> >
>
> IIRC we were told a while back that hosting a read-only (or even
> read-write) bugzilla on Apache infrastructure was a possibility?!
>
> Best wishes,
>
> Neil
>
> >
>