UX: Order of debugging, evaluate and breakpoints view

[Jaroslav Tulach]

Hi.
Please express your opinion, preferably by voting thumbs up/down at https://
github.com/apache/netbeans/pull/7496#issuecomment-2182909480

> Anyone else whats to vote? Should it be (from top to bottom):
>
>   debugging view, evaluate expression, breakpoints (vote +1)
>   debugging view, breakpoints, evaluate expression (vote -1)

I can update the PR to reflect the most preferred option then. Thank you.
-jt


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

[Jaroslav Tulach]

> 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 we handle issues of testing capacity, both ASF's limited CI
> resources and people, and the developer time needed to address
> problems raised on JDK 8 when adding new features and support for JDK
> 21+?
> - How do we address the issue of contributor disengagement,
> particularly amongst our most active contributors?  Who do you expect
> to pick all that work up?
> - And, bluntly, from my perspective, who's taking over release
> management for NB19+?
> 
> I said I would try and address reasons for blocking consensus by
> adapting the proposal.  I will continue to do so if other concerns are
> raised.  But I think it's fundamentally impossible to reconcile your
> points with the points raised by others.  Therefore, I guess this
> sadly but inevitably moves to a vote thread after we close discussion
> on Monday.
> 
> > The minimum JDK to run and test the NetBeans Platform and modules up to
> > VSCode... remains JDK 8.
> 
> I don't want to pre-empt Martin's input, which I know is coming, but
> it has been stated multiple times t

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

[Jaroslav Tulach]

Thank you Sváťa for writing this email. It open another "can of worms" in
the "lazy consensus" thread - in my opinion clearly rendering the "lazy
consensus" as obsolete.

I still need a bit of time to think about using your email strategically,
but in any case I'm happy. I am no longer the only one who gets all the
hater!

Thank you Sváťo!
-jt


Dne po 10. 4. 2023 1:16 uživatel Svata Dedic 
napsal:

> Please remember that the published proposal not only covered JDK8's
> fate, which we argue about right now, but also the idea to drop JDK11 in
> 2024. So take my
>
> * -1 (at the moment) for JDK8 phase out with NB19;
> * and ANOTHER -1 to the JDK11 plans as presented in this thread (but
> that should be discussed separately anyway, not hidden in dropping JDK8
> thread)
>
> Summary:
> - I do not think that dropping JDK8 now is a good idea
> - I do not think that sufficient relevant data for the decision was
> collected; I think that we did not even start to collect it.
> - I do think we can find and reach a reasonable compromise.
> - I propose some action items to make the decision better informed and
> based.
> - I offer coding help with compatibility bridges, analysis and/or
> migration of the code.
>
> TL;DR:
>
> I'd like to offer some coding support to retain JDK8 as well - but
> (which IMHO did not happened really during past heated exchanges) need
> to agree on support scope before committing. I'd like to emphasize that
> *runtime* compatibility should be treated separately from *development*
> environment requirements. I would also (now) ask to restrict from
> advocating language goodies - as there are different options to achieve
> that, not necessarily requiring the change of the codebase runtime
> requirements.
>
> I will quite from Ernie Rael's post (quoting stats from 2022):
> > even though Java 11 had been available for more than a year. Since
> > then, the balance has shifted between these two LTS release versions.
> > More than 48% of applications are now using Java 11 in production (up
> > from 11.11% in 2020) with Java 8 a close second, capturing 46.45% of
> > applications using the version in production.
>
> There was an idea to basically tell users with requirements for older
> JDKs (now 8, 11 in 2024) they should use the last released platform
> (NB18) that supports their environment. This really mean to *abandon the
> users*, as they will not receive any new features or bugfixes. While
> maintenance effort surely requires work if we still support JDK8,
> porting features (albeit selectively) back to old platform requires even
> usually much more effort. The offer that platform users do that for us
> may seem formally correct, but in reality it requires deep knowledge of
> many parts of the IDE, not just knowledge of the 'system parts' affected
> by JDK differences. Exemplified on myself, although I could be able to
> assist to develop bridges for different JDK versions for features
> determined as necessary for the new codebase (with possible graceful
> degradation or function disable on old runtimes), I sincerely doubt I
> would be able to assist with backporting a user-facing feature. I
> believe this is a general case, as the 'domain knowledge' is far more
> scarce than the knowledge of system libraries.
> So the seemingly positive approach, it turns out to be rather offensive
> in its implications to platform users, which is an outcome I do not like.
>
> This could be eventually barely acceptable in case of JDK8, I do not see
> reasonable to set minimum JDK to 11 at all. The reason is that while
> JDK8 has support cycle of 11 years (2015 released, 2026 EOLed by RH /
> IBM), JDK 11 has a super short shorter cycle despite being LTS (2021-24)
> and JDK17 just 6 years (2021-2027). From this perspective, forcing the
> users to upgrade JDK 8 > JDK 11 by NB19 in 2023, and then again to JDK17
> by (even if ve move OUR deadlines) right during 2024 given the *upstream
> support ceases for 11* in 10/2024, is ... a very bad idea.
>
> I've read the thread again, and I must think there's a lot of heated
> feelings, but very little of hard data. Let me say I understand (some
> of) the urge to upgrade and I'd like myself to be able to use some
> JDK11+ APIs in NB platform (but also pretty sure that other upgrade
> proponents are interested in *different* sets of APIs). But there are
> different perspectives - so important IMHO that I am willing to offer my
> personal time to support older JDKs, too.
>
> In fact, *we  all* (IMHO and me explicitly included) never went as far
> as to write down the fact and consolidate the info to get the overall
> picture. The consolidated list is important so the maintenance burden
> could become more obvious even to nonbelievers - or, in other hand, the
> JDK8 preservation may turn not such high barrier, and JDK11 features not
> as critical to outweigh the JDK8 drop for the whole codebase. We do not
> have AFAIK such an overview. We did not even start to collect such 

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

[Jaroslav Tulach]

Dne středa 5. dubna 2023 22:32:18 CEST, John Kostaras napsal(a):
> -1
> 
> Java 8 is also LTS and many out there are still stuck to it. I support
> Jarda, too.

Thank you John. There is a reason why JDK8 is LTS, right? When I was working 
with your organization I could see how important backward compatibility is. I 
could see the environment you were working in and also the previous (not based 
on NetBeans Platform) solution  - I could see that it was maintained for way 
more years than a "normal developer" can imagine.

I was proud to see your group selecting the NetBeans Platform and I got even 
more motivated to keep the promise of backward compatibility because of that! 
Dropping ability of the NetBeans Platform to run on JDK8 needlessly (yes, I am 
absolutely convinced it is needless; as we can find a way to "Run on JDK8, use 
JDK11 APIs!" - http://wiki.apidesign.org/wiki/AlternativeImplementation - 
without dropping JDK8 support fully) is against everything I have always been 
promoting as an API designer.

-jt

PS: I am sorry to see you changed your vote. However I can understand that - 
there is a lot of pressure (public as well as private) and one almost feels 
like an enemy being on the side of backward compatibility. 

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

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

[Jaroslav Tulach]

Thank you Toni for stepping out and publicly sharing your experience as a long 
time NetBeans Platform consultant.

You have met hundreds of people using NetBeans Platform in your career (more 
than I met) and you know how important backward compatibility is for their 
decisions and their trust in the NetBeans Platform.

Dropping ability of the NetBeans Platform to run on JDK8 needlessly (yes, I am 
absolutely convinced it is needless; as we can find a way to "Run on JDK8, use 
JDK11 APIs!" - http://wiki.apidesign.org/wiki/AlternativeImplementation - 
without dropping JDK8 support fully), is going to break the promise me, you 
and the NetBeans team was giving NetBeans Platform users since 1997!

I cannot let that "just" happen. Thank you for your vote and for helping me 
not be alone in this "NetBeans Platform heritage" fight. Thank you!
-jt

Dne středa 5. dubna 2023 18:25:22 CEST, toni.ep...@eppleton.de napsal(a):
> -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 

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

[Jaroslav Tulach]

-1

Background: http://wiki.apidesign.org/wiki/Portability


Alternative:

- I will maintain what ever needs to be maintained to keep JDK 8 CI tests 
running

- From Apache NetBeans 19, the minimum JDK required to build and run
the IDE will be JDK 11.

- The minimum JDK to run and test the NetBeans Platform and modules up to 
VSCode & Jackpot remains JDK 8.

- Usage of JDK11, JDK17, etc. API is possible in dedicated modules via http://
wiki.apidesign.org/wiki/AlternativeImplementation


Justification:

Writing in Java (a language designed to write once and run everywhere) greatly 
increases portability. However there is another axis hurting portability - the 
supported JDK version. Of course, should a library be widely used, it has to 
support as oldest JDK as possible. These days it is JDK8 - the primary reason 
being that Android supports JDK8 - as such, should a library aspire to be used 
on Android (as well as regular Java), it needs to stick to version eight.

There's transitivity of non-portability - the portability of the final 
application cannot be bigger than portability of the least portable library 
used. This applies also to 3rd party dependencies a framework or library has: 
again their non-portability may negatively affect portability of such framework 
or library. 

Of course, writing portable libraries is harder. It requires more work from 
the API author, more self-control, more suffering. However such suffering is 
justifiable. There is usually a single API writer, but there are many users to 
it. What matters is to simplify and improve experience of those API users - 
own author suffering doesn't matter that much.

> # Proposed policy
> 
> * Apache NetBeans 18 will be the last release to support running the
> platform on JDK 8.
> 
> * From Apache NetBeans 19, the minimum JDK required to build and run
> the IDE or platform will be JDK 11.
> 
> * Future releases will take an "LTS-1" strategy for building and
> running (and CI testing) of the IDE and platform. Three JDKs will be
> supported at any one time - the current JDK, plus the previous two LTS
> releases. eg. NetBeans 20 and 21 (Nov 2023 / Feb 2024) will support
> JDK 11, 17 and 21. NetBeans 22 (May 2024) will support JDK 17, 21 and
> 22.
> 
> ## Background
> 
> The Apache NetBeans IDE has officially required JDK 11 to build and
> run since NetBeans 13 in March 2022. The platform (and unofficially
> the IDE) have continued to support running on JDK 8 - all modules
> requiring a higher JDK must currently be optional. Various tests have
> continued on JDK 8.
> 
> This situation is causing issues as workarounds must be found for
> currently non-optional features that have dependencies or other
> requirements for running on a higher JDK (eg. Maven indexing / Lucene
> [1]). It's causing delays, complications and missed testing time in
> integration of new features (eg. problems merging support for EE 10
> [2]). Supporting an increasing range of JDKs is causing increasing
> workload, both for people and CI. Meeting the challenges of deprecated
> (for removal) features in the JDK is also complicated by the
> additional JDK requirements.
> 
> ## Notes
> 
> * Apache NetBeans users will continue to be recommended to use the
> current or latest LTS JDK to run the IDE.  The IDE will continue to
> support users developing projects for/with JDK 8, for as long as
> nb-javac and other dependencies allow.
> 
> * This proposal specifically doesn't address when the default bytecode
> level across the codebase is increased. This can happen when required,
> but non-optional modules 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/Maili

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

[Jaroslav Tulach]

> >> https://github.com/apache/netbeans/issues/4904
> >> 
> >> see also 'priority:high' label for more,
> > 
> > The issue says "Many tests fail on JDK 11" - how does that compare to JDK
> > 8?
> well. You mostly see this while trying to fix them. It always requires
> extra work to keep supporting 8 too.

The "extra work" is "keeping the code that already works"! We have code that 
works on JDK8 and there is no "extra work" to let it run on JDK8! Adding one 
additional `if (JDK11+)` check and writing new code is the "extra work", but 
it has nothing to do with supporting JDK8!

> > I am a guy who cares about compatibility (of NetBeans): Please tell me if
> > there is a test that doesn't work on JDK 8 and needs to be fixed.

I am still willing to maintain JDK8 tests, CI & etc.

> With every new JDK release it will become more difficult to keep
> supporting JDK 8 as runtime. 

No. That is not true. The code exists and works. You don't have to do anything 
special to continue support it.

> It also becomes increasingly difficult to
> motivate myself to fix JDK 8 issues in my freetime. 

I can imagine that. However we are not coding NetBeans to please ourselves, 
but to please our users. NetBeans Platform users need JDK8 support. That's why 
I am volunteering to maintain and run the CI & tests on JDK8.

-jt



> If I see PRs which
> fix edge cases in java-version parsing code which could be already
> solved by simply using the JDK 11 API for it, I am just asking myself:
> why are we doing this? It is not one thing which is the problem, its a
> million paper cuts.
> 
> -mbien
> 
> 
> [1] https://www.eclipse.org/lists/jakartaee-platform-dev/msg03898.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: NetBeans is a framework was: Lets talk about JDK 8 (new year edition)

[Jaroslav Tulach]

Late reply, sorry Antonio. I've just found your message.

Dne úterý 14. února 2023 20:52:28 CEST, Antonio napsal(a):
> Hi all,
> 
> I'm afraid I don't have time to read the whole thread. That's a pity,
> because it looks fun!
> 
> So I'll ask just a single queston to try to understand the situation.
> 
> On 9/2/23 5:38, Jaroslav Tulach wrote:
> > I was my NetBeans libraries to be as portable as possible and also run on
> > Android. I want to use `Lookup` & co.
> > -jt
> 
> I understand that you want to run Lookup & Co in Android, but I imagine
> you don't want to run the Enterprise cluster in Android, right? Either
> that or you sport a huge Android tablet/phone!

Right, I don't care about the "clearly IDE" clusters like `enterprise`.On the 
other hand I do care about VSCode integration and I do care about Jackpot. I 
want Jackpot to continue to run on JDK8 for many years to come.

> Question is: since NetBeans is modular and we now have a powerful Github
> action powered build system that compiles in thousands of different Java
> versions (and more to come by next year)...
> 
> ...Wouldn't it be possible to try to keep Lookup & Co (i.e. the platform
> cluster and probably a few others) binary compatible with JDK8 (with a
> specific Github action or something), and let the rest of clusters
> evolve with the times?

Yes, that sounds like a plan. However there is no need to draw the JDK8 vs. 
JDK11+ line along the clusters - we can use JDK11+ API in platform thanks to 
the modular NetBeans runtime system. I wrote a blog post about it:

http://wiki.apidesign.org/wiki/AlternativeImplementation

E.g. I am for focusing on modern JDKs, but the (platform/core) code has to be 
compiled to run on JDK8 and appropriate unit tests must pass on JDK8.
-jt




-
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: Lets talk about JDK 8 (new year edition)

[Jaroslav Tulach]

Thank you for your reply Neil.

> > > I hope everyone recovered from the last JDK 8 thread and is ready for
> > > the first JDK 8 thread of 2023 :)
> > 
> > Nobody recovers from these threads with you guys without wounds.
> > 
> > -1 (I mean veto) on dropping JDK 8 support.
> 
> If this were a lazy consensus thread, and we're not there yet, I'd
> expect a -1 

As you probably know, I am not participating in day-to-day development of 
NetBeans. It may happen I miss the vote thread - technically it might be 
presented as my mistake, but in reality it would be an obstruction, because 
everyone of you shall know:

I am voting against dropping support for JDK 8.

At any vote you ever call - even if I miss it. Please be so nice and make sure 
I know that a vote is about to happen. Otherwise I will challenge that vote at 
Apache authorities.

> to cover a lot more about an alternative way forward,
> addressing the resource issues, testing capacity constraints, peoples'
> time, priorities in supporting JDK 21+, release headaches, etc.

That's what I have been providing to you for the last three years (at least). 
You were never listening to me. Whenever I tried to move NetBeans IDE forward, 
while keeping the wide usability of NetBeans Platform, you said no.

Well, it is my turn now. I am saying no to "blind" dropping of JDK 8 support. 

> I hope we can find a consensus way forward on all that, but if not we
> end up with a majority vote on the issue.

I certainly hope we find a consensus. That was always the goal behind all my 
proposals in the last few years. 

Threatening with a "non-veto" vote on a code issue is a bit nasty, but I can 
live with it. Just keep me informed, so I can mobilize supporters.

> And soon we'll end up with 8, 11, 17, 21 and 22-ea.  That does not
> feel sustainable.

Why not? It is a machine doing the testing and it runs "for free". Anyway if 
you want to simplify the matrix - then drop 11 or 17 or 21 - they are all the 
same anyway. The the important thing is the bottom and then whether it shall 
be JDK8 or not!

Let the negotiations begin!
-jt




-
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: Lets talk about JDK 8 (new year edition)

[Jaroslav Tulach]

Thank you for the pointers Michael.

> >> This means we need either 1) a volunteer who would like to spend time
> >> and fix JDK 8 tests,
> > 
> > OK, tell me what to do.
> 
> as recap:
> 
> this thread was started to notify that a JDK 8 issue was blocking a
> fairly big Jakarta EE PR (#4692) which made only sense under JDK 11
> anyway. 

Are you saying `enterprise` cluster requires JDK 11 and cannot run on JDK 8? 
It is a relatively huge PR and it is not easy to get my head around it. 
Anyway, there is for example
https://github.com/apache/netbeans/pull/4692/files?file-filters%5B%5D=.properties&show-viewed-files=true#diff-6a741863ce06039216c34ea7e2d656c1c98044c11587a52b90fa82a6a9bc5097R19
which claims the module runs on JDK 8 - e.g. where is the problem? That's all 
I am asking for: to run NetBeans on JDK 8 ;-)

I am not able to find the blocker...

> This was detected months ago and fixed less than a month ago by
> Neil - right before the NB 17 deadline as you can see in the discussion.
> That is why it had to be resolved quickly otherwise we would have
> another release with almost no Jakarta EE support.

Glad for NetBeans to support Jakarta EE. Anyway I have to admit, historically 
the `enterprise` modules were always special - nobody really uses them as a 
"NetBeans Platform" - e.g. if you want to drop support for old JDKs in 
`enterprise` cluster - be it! It is (and always has been) a "user facing" 
cluster anyway.

> Help is always appreciated but it is late in this particular case,

Honestly, `enterprise` cluster has always been a lost case. Let's try to save 
the more important clusters!

> we have some umbrella issues here for example where contributions are
> welcome:
> 
> https://github.com/apache/netbeans/issues/4904
> 
> see also 'priority:high' label for more,

The issue says "Many tests fail on JDK 11" - how does that compare to JDK 8? 
Because the problem of many tests failing on JDK 11 has always been that JDK 
11 is incompatible with JDK 8. That's completely different problem - it is a 
problem of the JDK!

I am a guy who cares about compatibility (of NetBeans): Please tell me if 
there is a test that doesn't work on JDK 8 and needs to be fixed.

Summary: if you guys want to support JDK 11, then it is great. Do it! I am 
willing to work as much as I can to **not drop** JDK 8 support. Tell me what 
is blocking you with JDK 8 support and I fix it.

-jt




-
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: Lets talk about JDK 8 (new year edition)

[Jaroslav Tulach]

Dne úterý 10. ledna 2023 15:16:35 CET, Michael Bien napsal(a):
> Hello devs,
> 
> I hope everyone recovered from the last JDK 8 thread and is ready for
> the first JDK 8 thread of 2023 :)

Nobody recovers from these threads with you guys without wounds.

-1 (I mean veto) on dropping JDK 8 support.

> The commit validation job is currently testing on 8, 11, 17 and 20-ea.

Good.

> This means we need either 1) a volunteer who would like to spend time
> and fix JDK 8 tests, 

OK, tell me what to do.
-jt




-
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

NetBeans is a framework was: Lets talk about JDK 8 (new year edition)

[Jaroslav Tulach]

NetBeans isn't just an IDE, but it is a framework!

When designing frameworks and libraries that shall be widely adopted it is 
important to increase portability as much as possible. If an API can be used 
on different systems, different configurations, the amount of users including 
such API in their applications grows.

The best way to hurt portability is to depend on a 3rd party API that isn't 
portable. Depending on Win32 API is one such example. Of course, 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 be aspire to be used on 
Android (as well as regular Java), it needs to stick to version eight. Btw. 
not that many years ago, Android only supported JDK6 and many libraries had to 
stay with JDK6 APIs and language.


Supporting the ancient JDK gives the application writers using such library or 
framework a freedom to choose their JDK. The application writers can then run 
on oldest or newest JDK. That's the kind of freedom they want. However 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. 

I was my NetBeans libraries to be as portable as possible and also run on 
Android. I want to use `Lookup` & co.
-jt




-
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: https://netbeans.apidesign.org/maven2/ - problem

[Jaroslav Tulach]

Thanks for the notice. I see how quickly I can fix the certificate.
-jt


Dne so 28. 1. 2023 13:52 uživatel Neil C Smith 
napsal:

> On Fri, 27 Jan 2023 at 21:23, Piotr Hoppe  wrote:
> > The https://netbeans.apidesign.org/maven2/ has a problem with the
> > certificate. The certificate has expired.
>
> Maybe try contacting Jaroslav directly about it.  It's nothing we have
> control over.
>
> 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: Test Netbeans PR on Mavenized NB Platform application

[Jaroslav Tulach]

Long time no see, Mathieu!

There is a staging repository: https://repository.apache.org/content/groups/
staging/org/netbeans/modules/ but it looks a bit outdated.

Eric, is that intended or shall we be producing NetBeans dev bits regularly?
-jt



Dne sobota 8. října 2022 21:22:07 CET, Mathieu Bastian napsal(a):
> Hi folks,
> 
> I was called out in a recent PR
>  to
> test it with my NB Platform application. I'm willing to do so but I need
> some guidance.
> 
> My application is mavenized. What is the simplest way to test this PR
> locally with the dev version of Netbeans? For instance, can I create a
> "RELEASE160-SNAPSHOT" version locally via a command? If I had this, I could
> easily switch my application's NB Platform version to this dev version and
> test the change.
> 
> Much appreciated!
> 
> Mathieu





-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: [DISCUSS] Drop separate platform source and binary zip from release artefacts?

[Jaroslav Tulach]

Drop them.

I do care about NetBeans Platform, but people who use it shall use Maven 
artifacts to begin with these days.

If they really want a ZIP distribution, they can download IDE and keep just 
the platform cluster.

-jt

Dne čtvrtek 20. října 2022 12:28:16 CET, Neil C Smith napsal(a):
> Hi All,
> 
> Every release we include source and binary zip artefacts for the
> platform alone.  eg.
> https://dist.apache.org/repos/dist/release/netbeans/netbeans-platform/15/
> 
> Even the source zip is treated as an artefact of the main release.
> It's not voted on separately, and I don't know how many other people
> bother to check them?
> 
> They seem like an added complexity to the release process with minimal
> benefit (and a few issues). I'm not sure we link them in from
> anywhere?  I'm not sure if there's much of a need for them?
> 
> So, does anyone have a good argument or use case for continuing to
> include these?  Otherwise, I plan not to include them as artefacts in
> the next (NB16) release vote.
> 
> 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

Jackpot has to run on ancient JDK was: nb-javac for building NetBeans itself

[Jaroslav Tulach]

> This would mean that NB_the_IDE (not the platform) would not be able to
> _run_ on JDK 8 anymore (thunder in the background), it would be locked
> to the current JDK release which is already conveniently synced with
> NB's release cycle.


Michael,
NetBeans Platform needs portability. We have to be able to run on JDK8 
including our Java related tools.

Here is my take on that: https://lists.apache.org/thread/
3pt699bs18g1xp6tw8bdno82bqtrrj8b

Plus there is another reason that has just come to my mind: Jackpot. Jackpot 
is a build tool and as such it also needs portability. If we want to increase 
usage of Jackpot in other project, we need to give them freedom to choose 
their JDK and stop thinking about requiring them to run on the latest JDK!

-jt




-
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-javac for building NetBeans itself

[Jaroslav Tulach]

Dne středa 26. října 2022 22:53:13 CET, Eric Bresie napsal(a):
> Sorry I’m not in the know here from a who developed what but…
> 
> Since the below is forked from
> 
> https://github.com/oracle/nb-javac
> 
> Is that going to be a problem?
> 
> Or is that the beauty of open source development (i.e. fork it, enhance it,
> rebrand it [maybe nb-jc], etc. - license permitting)?

Hello Eric,
it is the beauty of open source development. Original maintainers give up on 
the project and I took over with the help of few friends. The nb-javac 
development is happening at https://github.com/JaroslavTulach/nb-javac/ now.

-jt


> > I take the above back -- nb-javac is developed by Jaroslav Tulach, and
> > whoever contributes, e.g., Dusan Balek.
> > 
> > https://github.com/JaroslavTulach/nb-javac/
> > 
> > Where should it be, Neil? It can't be here at Apache because of its
> > licensing. Isn't it fine where it is and under active development via
> > Jaroslav and others?
> > 
> > Where should it be on Maven Central where it is not versus where it is
> 
> now?
> 
> > Gj





-
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-javac for building NetBeans itself

[Jaroslav Tulach]

Dne úterý 25. října 2022 11:02:07 CET, Neil C Smith napsal(a):
> On Tue, 25 Oct 2022 at 08:06, Jaroslav Tulach  
wrote:
> >  JDK `javac` drops support for old `-target` versions. E.g. version 11 can
> >  no> 
> > longer target 1.5 bytecode:
> 
> Doesn't that take nb-javac beyond ever being just an automated
> backport of the current javac to run on older JDK?

nb-javac is an automated backport of the latest JDK's javac to run on JDK8+. 
No change here.

> I'm confused!  Wasn't the original proposal (and our existing usage of
> it) about using nb-javac to support later source and target while
> running on an older JDK.  This also adds supporting older source and
> target while running on a newer JDK?

By fixing the compiler in the build script (by downloading it from Maven 
central) you will be able to build such version of NetBeans on JDK33+ even if 
it drops support for any `-target` NetBeans currently needs.

If we stick using `javac` from the JDK the NetBeans build runs on, then at one 
moment you will need to download an ancient JDK to built old version of 
NetBeans as JDK33+ would be "too modern".

Let's use the JDK as a runtime only. Let's stop relying on its compiler. The 
build will be more reproducible.
-jt




-
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

NetBeans Platform Needs Portability was: nb-javac for building NetBeans itself

[Jaroslav Tulach]

Dne středa 26. října 2022 5:48:28 CET, Laszlo Kishalmi napsal(a):
> I kind of like the idea let nb-javac go, not depend more on it. 


Guys,
you are looking at the problem from an IDE perspective. However NetBeans is 
also a platform!

When designing frameworks and libraries that shall be widely adopted it is 
important to increase portability as much as possible. If an API can be used 
on different systems, different configurations, the amount of users including 
such API in their applications grows. There are hundreds of applications 
written on top of NetBeans Platform are cannot force them to run on latest JDK 
only.

Supporting the ancient JDK gives the application writers using NetBeans as a 
framework a freedom to choose their JDK. The application writers can then run 
on oldest or newest JDK. That's the kind of freedom they want.

We have all seen what problems happen when an important 3rd party library 
(Lucene) decides to drop support for older JDK. NetBeans Platform was always 
well known for carrying about its users - I certainly value everyone who 
builds its app on top of NetBeans Platform.

Many of such applications are still running on JDK8. Hence I want NetBeans 
Platform to run fine on JDK8.
 
-jt

PS: I am not a guy who wants to live in past, however! That's why I am offering 
you various ways to move forward, without hurting NetBeans Platform 
Portability.




-
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-javac for building NetBeans itself

[Jaroslav Tulach]

 JDK `javac` drops support for old `-target` versions. E.g. version 11 can no 
longer target 1.5 bytecode:

```
$ /jdk-11/bin/javac -source 1.5 -target 1.5 Hello.java
error: Source option 5 is no longer supported. Use 6 or later.
error: Target option 1.5 is no longer supported. Use 1.6 or later.
```

and such "dropping" constantly continues and happens all the time. For example 
JDK-17 cannot target 1.6 anymore:

```
$ /jdk-17/bin/javac -source 1.6 -target 1.6 Hello.java
error: Source option 6 is no longer supported. Use 7 or later.
error: Target option 6 is no longer supported. Use 7 or later.
```

as a consequence one cannot use the latest JDK to build (not so old) versions 
of NetBeans. This decay bugs me a lot. 

I want to use JDK/JRE as a runtime (newest JDK can still run the 1.0 bytecode 
format) and separate compiler from such runtime. Then the world is going to be 
a better place.
-jt

Sidenote:
> I think Michael Bien answered this: "btw javac has actually a public API, it
> won't simply disappear from one release to the other without warning"

NetBeans use of `javac` goes far beyond its public API. I believe there is a 
little relevance concluding the important aspects of javac remain based on 
existence of some public API.

Dne úterý 25. října 2022 3:16:38 CEST, Eirik Bakke napsal(a):
> > Right now, when we build NetBeans, we’re using the javac from the JDK that
> > we’re using to do the build — so that we’re dependent on the JDK team,
> > which can decide to drop features.
> 
> Does the JDK ever drop features? Are we currently dependent on unofficial or
> experimental JDK features relating to the official javac?
 
> I think Michael Bien answered this: "btw javac has actually a public API, it
> won't simply disappear from one release to the other without warning"
 
> I agree with Michael Bien here:
> 
> > I would approach this from a different POV and ask why NB requires
> > nb-javac in the first place, instead of trying to find more stages in the
> > NB life cycle where we can add it.
> 
> Much better to keep NetBeans building with the standard JDK.
> 
> -- Eirik
> 
> -Original Message-
> From: Michael Bien  
> Sent: Monday, October 24, 2022 4:27 PM
> To: dev@netbeans.apache.org; Ernie Rael 
> Subject: Re: nb-javac for building NetBeans itself
> 
> On 24.10.22 22:15, Ernie Rael wrote:
> 
> > On 22/10/24 8:58 AM, Michael Bien wrote:
> > 
> >> On 24.10.22 17:27, Ernie Rael wrote:
> >> 
> >>> The link to apache's guidelines for voting was clarifying for me. 
> >>> I'd like to see a more technical discussion.
> >>
> >>
> >>
> >> for me too, I withdrew the -1 vote the moment I realized that this 
> >> could qualify as veto since this discussion would fall into the 
> >> code-change category.
> >>
> >>
> >>
> >> Luckily withdrawing vetos is legal, which is useful since I didn't 
> >> even intend to veto anything :)
> >>
> >>
> >>
> >>
> >>> And I have to mention one thing that really bugged me: a lot of the 
> >>> discussion seemed to have the assumption that it's easy for users to 
> >>> use the latest JDK; I think that's just not accurate (but again 
> >>> don't have hard data). For me, I have to use Gradle 6.8.x so I can 
> >>> not use the latest JDK. If it's true in general that many/most users 
> >>> can not use the latest JDK, that seems like an extremely important 
> >>> data point.
> >>
> >>
> >>
> >> Yes I heard about this issue. We should take a look if this can be 
> >> somehow solved. Its certainly not optimal to be required to change 
> >> the runtime JDK of the IDE when switching between projects which use 
> >> different gradle versions.
> >>
> >>
> >>
> >> lets try to solve this without nb-gradle if possible.
> > 
> > I only brought that up as an example of a situation where can't use 
> > the latest JDK. I wouldn't be surprised if most users have 
> > restrictions on which JDK can be used and/or targeted.
> 
> 
> This doesn't influence the target JDK at all. Java 8 shops don't swap out
> the build-in JDK 11 of android studio if they write an app. It is just the
> runtime of android studio, it has no other viral effects or influences your
> support contracts with specific vendors.
 
> -mbien
> 
> 
> 
> >>
> >>
> >> best regards,
> >>
> >>
> >>
> >> michael
> >>
> >>
> >>
> >>
> >>>
> >>>
> >>> -ernie
> >>>
> >>>
> >>>
> >>>
> 
> 
>  Maybe a straight vote on this is the way forward, and we live with 
>  the consequences either way?!
> 
> 
> 
>  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: [DISCUSS] Shall NetBeans use fixed version of javac compiler?

[Jaroslav Tulach]

FYI: I've prepared https://github.com/apache/netbeans/pull/4795

Just like Kotlin offers two benefits:

> and Ernie nicely summarized them as:
> > - language specification independent of the JDK
> > - compiler version specified as part of project build script

I believe it is beneficial to bring those benefits to Java as well. Let 
NetBeans 
project benefit from using NbJavac more!

-jt

Dne neděle 9. října 2022 19:21:03 CEST, Jaroslav Tulach napsal(a):
> Thank you for your reactions.
> 
> If you dedicated 40 minutes and watched my "Forget/Ignore Kotlin, use
> Java19" talk at https://www.youtube.com/watch?v=ua-8ySwFgqg and didn't get
> convinced about anything, then I doubt additional email messages can change
> something. Anyway thanks for your reactions, I've only received positive
> feedback so far.
> Emmanuel wrote:
> > PS I loved the beard, I didn't recognize you at first glance
> 
> Laszlo wrote:
> > Thanks for sharing the presentation!, I really enjoyed it. +1 for that
> > mustache!
> 
> Thank you guys. This is why I was avoiding barber since the COVID outbreak!
> 
> 
> However let's return back to the topic of the talk. Kotlin has some benefits
> and Ernie nicely summarized them as:
> > - language specification independent of the JDK
> > - compiler version specified as part of project build script
> > - language quickly evolves
> > - still can be used to generate JDK8 code
> 
> I believe that Java ecosystem would be better, if we adopted some of these
> benefits as well.
> 
> Let's only focus on the first two now. Let's make the compiler part of the
> project build script first. That will detach the compiler/language from the
> JDK. The benefit is obvious - one will be able to build on JDK 37+ ;-) While
> JDK's `javac` compiler drops supported target options like crazy, JDK still
> knows how to execute even the oldest bytecode. By having a compiler "part
> of the build script" - our builds will be more reproducible in the future,
> even with the newest JDKs.
> 
> Please note that for this to happen, I'll be fine with any javac family
> compiler available on Maven central. E.g. I will use `nb-javac`: https://
> cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac
> 
> I'd start slower this time by eating our own dog food. I'd just modify
> NetBeans build script to compile NetBeans source with nb-javac. This shall
> be the non-controversial part of "improve Java by mimicking Kotlin" project
> - all comments I've heard so far attack other aspects - nobody criticized
> including a compiler into the build script vision.
> 
> Best regards and keep the comments coming. I am reading them all.
> -jt
> 
> Dne středa 5. října 2022 19:47:24 CEST, Jaroslav Tulach napsal(a):
> > Hi.
> > Recently I brought [Frgaal retrofit compiler](http://frgaal.org) to your
> > attention again. There was a [PR-4682](https://github.com/apache/netbeans/
> > pull/4682) and then a discussion in the thread about (not) supporting ecj
> > in NetBeans: https://lists.apache.org/list.html?dev@netbeans.apache.org -
> > thank you for your comments.
> > 
> > It all boils down to a simple question: Shall NetBeans try to improve
> > shortcomings of the JDK?
> > 
> > I have recently given a talk [Forget/Ignore Kotlin, use Java19](https://
> > www.youtube.com/watch?v=ua-8ySwFgqg). There is a slide describing the
> > benefits of Kotlin around 5th minute. Clearly the fact that the Kotlin
> > language quickly evolves and still can be used to generate JDK8 code is a
> > huge benefit.
> > 
> > Frgaal (described around 25 minute) can do the same. It has been modeled
> > to
> > mimic the Kotlin model:
> > - language specification independent of the JDK
> > - compiler version specified as part of project build script
> > 
> > Moreover Frgaal is 100% compatible with future Java language specification
> > - easy to drop it after switching to newest JDK. Overall it is way easier
> > to adopt latest Java thru Frgaal than trying to switch to a completely
> > new language. Why do I have to explain it again and again?
> > 
> > NetBeans can support Frgaal without any problems as it is also (just like
> > nb- javac) a member of the Javac family. All these compilers generate
> > exactly the same errors and provide the same WYSIWYG experience. Same
> > errors in the IDE, same on the command line, same on the CI.
> > 
> > All that is needed is: We have to realize that "innovation happens
> > elsewhere" and make Java better than the one produced by the JDK team!
> 

Re: [VOTE] Release Apache NetBeans VSCode extension 15.0.301

[Jaroslav Tulach]

+1 (binding)

Dne úterý 11. října 2022 13:41:15 CEST, Martin Balin napsal(a):
> Dear community,
> let's update the Apache NetBeans Language Server extension on VSCode
> Marketplace with improved version 15.0.301
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/15.0.30
> 1/ 
> The primary voting artifact is the source
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/15.0.301
> /apache-netbeans-java-15.0.301-source.zip
 built from branch
> ‘vsnetbeans_1503`
> SHA-512 sum is:
> 1bb5933e23de63f6b4a34d46e0c7bc1599820590c27209564b7bf012bf65fe1ea074f8596c3
> ea2af5eb40da426880797d4f04c1f9ab196a21c9616648a1ddb06
> apache-netbeans-java-15.0.301-source.zip
 
> and PGP signature:
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/15.0.301
> /apache-netbeans-java-15.0.301-source.zip.asc
 
> Binary artifacts were built by
> https://ci-builds.apache.org/job/Netbeans/job/netbeans-vscode/1281/ /ci-builds.apache.org/job/Netbeans/job/netbeans-vscode/1182/>
 
> Use following commands to build your own 15.0.301 VSIX binary:
> 
> tmp$ unzip apache-netbeans-java-15.0.301-source.zip
> tmp$ $ ant build
> tmp$ cd java/java.lsp.server
> tmp$ ant build-vscode-ext -Dvsix.version=15.0.301 -D3rdparty.modules=none
> 
> In addition to the source ZIP file, we are also voting about convenience
> binary:
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/15.0.30
> 1/apache-netbeans-java-15.0.301.vsix SHA-512 sum:
> 
> 416ba38e0f255f8f2fd23e2eda8d2cda5b026907757a6cf84719e24256a16b20e39f1f4a6778
> 8c16cf2c9dfaab22b4aa5da7d3acbeb864636d8449a6c844aac4 
> apache-netbeans-java-15.0.301.vsix
 
> PGG signature:
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/15.0.301
> /apache-netbeans-java-15.0.301.vsix.asc
 
> The binary has been produced by the same job run #1281, from the same
> commit.
 
> This vote is going to be open at least 72 hours, vote with +1, 0, and -1 as
> usual. Please mark your vote with (binding) if you're an Apache NetBeans
> PMC member.
 
> Thank you,
> Martin Balín





-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: [DISCUSS] Shall NetBeans improve Java/JDK? Without Frgaal this time...

[Jaroslav Tulach]

Thank you for your reactions.

If you dedicated 40 minutes and watched my "Forget/Ignore Kotlin, use Java19" 
talk at https://www.youtube.com/watch?v=ua-8ySwFgqg and didn't get convinced 
about anything, then I doubt additional email messages can change something. 
Anyway thanks for your reactions, I've only received positive feedback so far.

Emmanuel wrote:
> PS I loved the beard, I didn't recognize you at first glance

Laszlo wrote:
> Thanks for sharing the presentation!, I really enjoyed it. +1 for that
> mustache!

Thank you guys. This is why I was avoiding barber since the COVID outbreak!


However let's return back to the topic of the talk. Kotlin has some benefits 
and Ernie nicely summarized them as:

> - language specification independent of the JDK
> - compiler version specified as part of project build script
> - language quickly evolves 
> - still can be used to generate JDK8 code

I believe that Java ecosystem would be better, if we adopted some of these 
benefits as well.

Let's only focus on the first two now. Let's make the compiler part of the 
project build script first. That will detach the compiler/language from the 
JDK. The benefit is obvious - one will be able to build on JDK 37+ ;-) While 
JDK's `javac` compiler drops supported target options like crazy, JDK still 
knows how to execute even the oldest bytecode. By having a compiler "part of 
the build script" - our builds will be more reproducible in the future, even 
with the newest JDKs.

Please note that for this to happen, I'll be fine with any javac family 
compiler available on Maven central. E.g. I will use `nb-javac`: https://
cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac

I'd start slower this time by eating our own dog food. I'd just modify 
NetBeans build script to compile NetBeans source with nb-javac. This shall be 
the non-controversial part of "improve Java by mimicking Kotlin" project - all 
comments I've heard so far attack other aspects - nobody criticized including 
a compiler into the build script vision.

Best regards and keep the comments coming. I am reading them all.
-jt

Dne středa 5. října 2022 19:47:24 CEST, Jaroslav Tulach napsal(a):
> Hi.
> Recently I brought [Frgaal retrofit compiler](http://frgaal.org) to your
> attention again. There was a [PR-4682](https://github.com/apache/netbeans/
> pull/4682) and then a discussion in the thread about (not) supporting ecj in
> NetBeans: https://lists.apache.org/list.html?dev@netbeans.apache.org -
> thank you for your comments.
> 
> It all boils down to a simple question: Shall NetBeans try to improve
> shortcomings of the JDK?
> 
> I have recently given a talk [Forget/Ignore Kotlin, use Java19](https://
> www.youtube.com/watch?v=ua-8ySwFgqg). There is a slide describing the
> benefits of Kotlin around 5th minute. Clearly the fact that the Kotlin
> language quickly evolves and still can be used to generate JDK8 code is a
> huge benefit.
> 
> Frgaal (described around 25 minute) can do the same. It has been modeled to
> mimic the Kotlin model:
> - language specification independent of the JDK
> - compiler version specified as part of project build script
> 
> Moreover Frgaal is 100% compatible with future Java language specification -
> easy to drop it after switching to newest JDK. Overall it is way easier to
> adopt latest Java thru Frgaal than trying to switch to a completely new
> language. Why do I have to explain it again and again?
> 
> NetBeans can support Frgaal without any problems as it is also (just like
> nb- javac) a member of the Javac family. All these compilers generate
> exactly the same errors and provide the same WYSIWYG experience. Same
> errors in the IDE, same on the command line, same on the CI.
> 
> All that is needed is: We have to realize that "innovation happens
> elsewhere" and make Java better than the one produced by the JDK team!
> 
> Anyone has guts to follow better-than-JDK vision? Then let me integrate
> Frgaal into NetBeans and bring the latest Java language features to users
> of older JDKs.
> -jt





-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: [DISCUSS] Supporting ecj in NetBeans

[Jaroslav Tulach]

> frgaal: compiler candy without new API, is just like alcohol-free beer.

One doesn't have to be completely drunk to enjoy the party...

> > they are not developed independently. Streams without lambdas would be
> > no fun.

...moreover this is the opposite implication! 

There are many libraries that can benefit from using lambdas. Many libraries 
that are easier to use with text blocks. Has there been any `record` in the 
JDK-15, btw.?

Telling people to avoid using the latest and greatest Java features just 
because they couldn't have fun with streams, is just completely missing the 
point! 

-jt





-
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

[DISCUSS] Shall NetBeans improve Java/JDK? With Frgaal?

[Jaroslav Tulach]

Hi.
Recently I brought [Frgaal retrofit compiler](http://frgaal.org) to your 
attention again. There was a [PR-4682](https://github.com/apache/netbeans/
pull/4682) and then a discussion in the thread about (not) supporting ecj in 
NetBeans: https://lists.apache.org/list.html?dev@netbeans.apache.org - thank 
you for your comments.

It all boils down to a simple question: Shall NetBeans try to improve 
shortcomings of the JDK?

I have recently given a talk [Forget/Ignore Kotlin, use Java19](https://
www.youtube.com/watch?v=ua-8ySwFgqg). There is a slide describing the benefits 
of Kotlin around 5th minute. Clearly the fact that the Kotlin language quickly 
evolves and still can be used to generate JDK8 code is a huge benefit.

Frgaal (described around 25 minute) can do the same. It has been modeled to 
mimic the Kotlin model:
- language specification independent of the JDK
- compiler version specified as part of project build script

Moreover Frgaal is 100% compatible with future Java language specification - 
easy to drop it after switching to newest JDK. Overall it is way easier to 
adopt latest Java thru Frgaal than trying to switch to a completely new 
language. Why do I have to explain it again and again?

NetBeans can support Frgaal without any problems as it is also (just like nb-
javac) a member of the Javac family. All these compilers generate exactly the 
same errors and provide the same WYSIWYG experience. Same errors in the IDE, 
same on the command line, same on the CI.

All that is needed is: We have to realize that "innovation happens elsewhere" 
and make Java better than the one produced by the JDK team!

Anyone has guts to follow better-than-JDK vision? Then let me integrate Frgaal 
into NetBeans and bring the latest Java language features to users of older 
JDKs.
-jt




-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: [DISCUSS] Supporting ecj in NetBeans

[Jaroslav Tulach]

Dne čtvrtek 29. září 2022 19:40:37 CEST, Matthias Bläsing napsal(a):
> Hi,
> 
> I'm the author of the referenced comment:
> https://github.com/apache/netbeans/pull/4682#issuecomment-1257208904
> 
> there is not integration of anything into the IDE. It is about making
> "new" JDK features available to older bytecode targets. 

Can I repeat your sentence, Matthias? Your comments "aren't related to 
integration of anything into the (NetBeans) IDE"? Neither frgaal, neither ecj? 
Is that really what you are saying? Then, great!

As nobody else expressed the desire to integrate `ecj` into NetBeans and 
Matthias comments aren't proposing to add support for `ecj` into NetBeans 
either, we can conclude that NetBeans are unlikely to support `ecj` in the 
near future. Thank you all for sticking to such a wise decision.

NetBeans biggest strength is the close adherence to latest JDK `javac` which 
provides the NetBeans users almost WYSIWYG experience when editing Java. 
Errors, warnings they see in the editor are just like what they get on the 
command line.
-jt

PS: Of course, when someone donates own work and decides to integrate `ecj` 
into NetBeans, nobody is going to stop such effort. We are a friendly community 
and happily accept contributions, right?




-
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

[DISCUSS] Supporting ecj in NetBeans

[Jaroslav Tulach]

Supporting `ecj` in NetBeans makes no/little sense. Let's have a discussion to 
agree on that.

Few times in the past (most recently at 
https://github.com/apache/netbeans/
pull/4682#issuecomment-1257208904) there was a note suggesting to support 
`ecj`. Usually such suggestion appears whenever I propose to use http://
frgaal.org retrofit compiler.

Using `ecj` makes no sense - the biggest strength of NetBeans is its WYSIWYG 
nature - errors in the editor are exactly the same as errors one gets on 
command line when executing `mvn` or `gradlew`. That's because NetBeans relies 
on the family of Javac compilers - be it `javac` from the latest JDK or our 
own  `nb-javac` port. 

`ecj` is completely different compiler. It has own bugs, own view of Java 
source code and it can never achieve the same WYSIWYG experience as `javac` in 
NetBeans provides. Supporting `ecj` seems like a step backwards. I am not 
going to stop anyone working on `ecj` support, but I believe the NetBeans 
project will have better prospects when it adheres to the family of Javac 
compilers.

As an author of https://cwiki.apache.org/confluence/display/NETBEANS/
Overview%3A+nb-javac plan, I believe there is no use of `ecj` in NetBeans.
-jt

PS: Yes, Frgaal does belong into the Javac family. It is a slightly modified 
version of the `javac` from the latest JDK that removes the (artificial) 
limitation that prevents `target < source`.




-
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: [platform] --nogui takes 20 seconds to finish

[Jaroslav Tulach]

Where the time is spent? For example according to VisualVM profiling?
-jt

> 10. 9. 2022 v 10:37, Patrik Karlström :
> 
> I'm starting a new platform application project that will normally be run
> in GUI mode and sometimes in CLI with --nogui set.
> 
> To my surprise, --nogui takes about 20 seconds to finish while starting the
> GUI and manually closing it takes only 4 seconds. This is for a new empty
> project with NB15 on Windows and Linux.
> 
> I'm on par with the steps described in
> https://netbeans.apache.org/wiki/DevFaqNonGuiPlatformApp.asciidoc#_how_can_i_make_my_netbeans_platform_run_in_gui_or_command_line_mode
> 
> What can be done to speed up the process?
> 
> /Patrik

-
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: Cleanup PRs shall not touch `.sig` files was: API snapshot review for NetBeans 15 - possible issue?

[Jaroslav Tulach]

Dne pátek 26. srpna 2022 13:29:54 CEST, Neil C Smith napsal(a):
> On Sat, 20 Aug 2022 at 07:37, Jaroslav Tulach  
wrote:
> > Executive summary: If a "cleanup PR" has to touch `.sig` files, then it is
> > not a cleanup!
> 
> Totally agree!
> 
> However, the interesting thing here is that if it wasn't for the
> bitshift value changes showing up in
> https://github.com/apache/netbeans/pull/4487 this might not have been
> picked up.
> 
> Shouldn't the constant value changes have also caused test failures in
> the original cleanup PR?

Hmm. Good point. The explanation very likely is: we are running "binary 
compatibility" check. E.g. not what happens after re-compilation, but what 
happens during linkage time.

`public static final int` constants are copied to the usage place by value at 
compilation time. E.g. removing such constant isn't binary incompatible! Just 
source incompatible! The bitshift made the change also binary incompatible as 
the previous values of the constants and the new values were different. 

Interesting behavior of sigtest. I wasn't aware of it.

> Maybe in Michael's CI changes we could also look at failing PRs that
> touch .sig files unless they have a particular label set on them (eg.
> API change)?

Labeling API changes by CI would be great!
-jt

> 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

Cleanup PRs shall not touch `.sig` files was: API snapshot review for NetBeans 15 - possible issue?

[Jaroslav Tulach]

Hello guys,
thanks a lot for dealing with the issue so nicely in PR-4498.

> Re: the bitwise shifts

The easiest way to avoid breaking an API is to not touch it. I have to admit I 
don't understand why the need to clean something up also includes innocent API 
constants?

> yeah this sounds like something we should revert. Since it is a cleanup 
> PR, reverting it should be safe.

+1

I'd also suggest to remember that cleanup PRs shall not touch API! There is no 
justification in breaking API just because we want to clean our codebase.

Thank you: https://github.com/apache/netbeans/pull/4498/files#r950657498

Executive summary: If a "cleanup PR" has to touch `.sig` files, then it is not 
a cleanup!
-jt

Dne čtvrtek 11. srpna 2022 19:50:30 CEST, László Kishalmi napsal(a):
> 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





-
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: Bringing apidoc back

[Jaroslav Tulach]

Amazing! Thank you for fixing the broken links.
-jt


Dne po 8. 8. 2022 19:51 uživatel Eric Barboni  napsal:

> Hi folks,
>
> I started a PR to clean up the api doc. The main goal is that we need
> javadoc to success with failonerror set to true. Because if it fails only
> architecture and api change are generated but not the javadoc.
>
>
> The most important issue is the following :
> On the master it’s currently not possible to build using jdk 11 because
> java.source.base need a classpath with nbjavac (jdk 18) (they may be other
> modules involved). I’m not sure if providing a javadoc for nbjavac could
> help as Neil comment.
> For being able to fix javadoc  issue in source
> - I use a jdk 18 to be consitent with the jdk nb-javac use.
> - I changed the javadoc checker to check all the html file to remove
> maximum issue
>
> And there is a lots of issues 😃
>
> fixed the apichanges,arch.xml
> fixed typos on doc ( like <  < ; )
> removed links that were using private/protected reference. (we expose
> only  org.netbeans.api.*, org.netbeans.spi.*) using our new
> netbeans.apache.org url as much as possible. And also coherent url
> pattern.
>
>
> So 1000 modifications later it compile on master with only a few bad links
> remaining
>
> Here is a list of the faulty links
>
> https://cwiki.apache.org/confluence/display/NETBEANS/NetBeans+apidoc+referenced+url
> That the second issue: the missing page from fomer netbeans website and
> blogs. Web.archive.org get them all.
>
> So I need your advise what to do with that.
> 1) Change the links to web.archiva.org
> 2) Remove the links
> 3) Copy from webarchive to our site but I'm unsure of the copyright here.
> 4) other idea
>
> In the case of 3) could we have.
> netbeans.apache.org/projects/autoupdate, netbeans.apache.org/projects/ui
>
> Best regards
> Eric
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: [RELEASES] Getting ready for NetBeans 15 branching

[Jaroslav Tulach]

Dne středa 29. června 2022 16:16:39 CEST, Neil C Smith napsal(a):
> It's not a release team job to decide what gets merged -
> that's for all reviewers.  And primarily, in my mind, the PR author
> should be making the initial call.  I'd like to suggest that all
> descriptions on PRs for delivery, at least when not linked to an
> issue, should include a short justification for inclusion.  Thoughts?

Example: https://github.com/apache/netbeans/pull/4422

Justification done. Reviewers are fine with the merge to delivery. Who is 
supposed to merge? Me or release coordinator?
-jt




-
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: JDK 18.0.2 is out but I don't think we have to refresh nb-javac this time

[Jaroslav Tulach]

Shouldn't we refresh to 19? I'd like to use pattern matching on records and
it is currently broken.

And frgaal 19-RC1 is already out!
-jt


Dne st 20. 7. 2022 22:33 uživatel Michael Bien  napsal:

> Hi devs,
>
> JDK 18.0.2 has three javac related bugfixes as indexed here:
> https://foojay.io/java-18/?quarter=072022&tab=component (search for javac)
>
>   - https://bugs.openjdk.org/browse/JDK-8286444
>
>   - https://bugs.openjdk.org/browse/JDK-8286855
>
>   - https://bugs.openjdk.org/browse/JDK-8282080
>
> they don't sound particularly interesting for NetBeans. So I don't think
> we have to refresh nb-javac this cycle.
>
> regards,
>
> -mbien
>
>
> -
> 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
>
>
>
>

[RESULT][VOTE] NetBeans HTML/Java API 1.8.1

[Jaroslav Tulach]

HTML/Java release 1.8.1 has been approved. Thank you.

+4 (binding) - Dušan, Eric, Toni & me

Let's release the bits!
-jt


Dne čtvrtek 7. července 2022 7:45:50 CEST, Jaroslav Tulach napsal(a):
> Hi.
> A bugfix release of HTML/Java API is needed. While trying to upgrade
> HTML/Java libraries in NetBeans/VSCode:
> https://github.com/apache/netbeans/pull/4040 - it has been found that
> additional bugfixes over 1.8 are needed.
> 
> This is the main voting artefact:
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-html4j/netbeans-htm
> l4j-1.8.1/netbeans-html4j-1.8.1.zip its sha512sum is
> 6540380491059525eab26b8f331f7f7098acce33063237fb591ba5aba2c6b09be29ff51ac991
> 971948ae57c74b86b32b6a09aa164b625f413ba9e2f7be9e8d2f and I signed it as
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-html4j/netbeans-ht
> ml4j-1.8.1/netbeans-html4j-1.8.1.zip.asc - these files were produced by
> https://ci-builds.apache.org/job/Netbeans/view/html4j/job/
> netbeans-html4j-release/12/ job run.
> 
> If you want to build from the source, then unzip and use following command:
> 
> netbeans-html4j$ mvn clean install -DskipTests
> 
> you can also run the command without `-DskipTests` and report a (non
> blocking) test failure. Right now the tests seem to be stable, but
> historically they have been a bit flaky.
> 
> Of course, to verify the new library works, you should have an HTML/Java
> project and switch it to the new version. If you don't have such project,
> you can create one in NetBeans 13: "New Project/Java with Maven/Java
> Frontend Application" - if that application works for you, then you can
> switch to locally built HTML/Java API by changing:
> 
> --- a/pom.xml
> +++ b/pom.xml
> @@ -15,7 +15,7 @@
>  js
>  
>  
> -1.7
> +1.8.1
>  11
>  1.0
>  2.13
> 
> If your application continues to work, everything is OK.
> 
> In addition to the main voting artifact, we are also about to approve the
> following Maven repository:
> https://repository.apache.org/content/repositories/orgapachenetbeans-1120/
> It has been produced by unzipping the main ZIP file and running:
> ```
> netbeans-html4j$ JAVA_HOME=/jdk-17/ mvn -Dgpg.keyname=xyz -Papache-release
> clean -DskipTests deploy
> ```
> I'll release it to Maven central if our vote passes.
> 
> Please cast your votes. The vote is going to be open at least for 72h.
> -jt





-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: [VOTE] NetBeans HTML/Java API 1.8.1

[Jaroslav Tulach]

+1 (binding)
-jt


Dne čtvrtek 7. července 2022 7:45:50 CEST, Jaroslav Tulach napsal(a):
> Hi.
> A bugfix release of HTML/Java API is needed. While trying to upgrade
> HTML/Java libraries in NetBeans/VSCode:
> https://github.com/apache/netbeans/pull/4040 - it has been found that
> additional bugfixes over 1.8 are needed.
> 
> This is the main voting artefact:
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-html4j/netbeans-htm
> l4j-1.8.1/netbeans-html4j-1.8.1.zip its sha512sum is
> 6540380491059525eab26b8f331f7f7098acce33063237fb591ba5aba2c6b09be29ff51ac991
> 971948ae57c74b86b32b6a09aa164b625f413ba9e2f7be9e8d2f and I signed it as
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-html4j/netbeans-ht
> ml4j-1.8.1/netbeans-html4j-1.8.1.zip.asc - these files were produced by
> https://ci-builds.apache.org/job/Netbeans/view/html4j/job/
> netbeans-html4j-release/12/ job run.
> 
> If you want to build from the source, then unzip and use following command:
> 
> netbeans-html4j$ mvn clean install -DskipTests
> 
> you can also run the command without `-DskipTests` and report a (non
> blocking) test failure. Right now the tests seem to be stable, but
> historically they have been a bit flaky.
> 
> Of course, to verify the new library works, you should have an HTML/Java
> project and switch it to the new version. If you don't have such project,
> you can create one in NetBeans 13: "New Project/Java with Maven/Java
> Frontend Application" - if that application works for you, then you can
> switch to locally built HTML/Java API by changing:
> 
> --- a/pom.xml
> +++ b/pom.xml
> @@ -15,7 +15,7 @@
>  js
>  
>  
> -1.7
> +1.8.1
>  11
>  1.0
>  2.13
> 
> If your application continues to work, everything is OK.
> 
> In addition to the main voting artifact, we are also about to approve the
> following Maven repository:
> https://repository.apache.org/content/repositories/orgapachenetbeans-1120/
> It has been produced by unzipping the main ZIP file and running:
> ```
> netbeans-html4j$ JAVA_HOME=/jdk-17/ mvn -Dgpg.keyname=xyz -Papache-release
> clean -DskipTests deploy
> ```
> I'll release it to Maven central if our vote passes.
> 
> Please cast your votes. The vote is going to be open at least for 72h.
> -jt





-
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: [PLUGINS][RELEASES] Preparation for NetBeans 15 plugins

[Jaroslav Tulach]

> The other option is we stop verifying by NetBeans version at all?

The question is: how much do we trust backward compatibility of NetBeans 
releases? We do check signatures with sigtest - e.g. it shall be compatible to 
great extent. Btw. I am still successfully using NBPython support from 8.1!

The last compatibility problems I remember were related to nb-javac - that one 
is however special. It is a 3rd party module which changes Trees API 
incompatibly and is hard to get working across multiple releases. Anyway since 
https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac the 
problem is solved.

Other potential problem is request to run on newer JDKs - not all old plugins 
may be ready for that.

That is all I can imagine. Overall I believe a single update center across 
releases could already work smoothly for 90-95%  of cases. The remaining cases 
however may need an (immediate) attention.

-jt




-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Bad links in javadoc

[Jaroslav Tulach]

https://github.com/apache/netbeans/pull/4342
-jt


Dne út 5. 7. 2022 16:01 uživatel Eric Barboni  napsal:

> The PR is merged, but to be usable in the build we need the jar with the
> PR in it.
> And then we will have a nice apidoc again. For master and 12.6-to 14
>
> Eric
>
> -Message d'origine-
> De : Ernie Rael <>
> Envoyé : lundi 4 juillet 2022 17:49
> À : dev@netbeans.apache.org
> Objet : Re: Bad links in javadoc
>
> On 7/4/22 1:19 AM, Eric Barboni wrote:
> > The issue is in the version we use of codesnippet,
> >   https://github.com/jtulach/codesnippet4javadoc.
> >
> > Building with jdk8 was ok but with 11 issue occurs The following PR
> > fixes the issue
>
> Is there some reason this PR is not merged?
>
> I recall reading that old javadoc should be regenerated for versions that
> have the broken links. While I suppose it's nice to fixup the broken
> revisions, that seems much less important than once again producing fully
> functional javadoc.
>
> -ernie
>
> > I encounter using modern codesnippet
> > version
> > https://github.com/jtulach/codesnippet4javadoc/pull/31f
> >
> > Eric
> > -Message d'origine-
> > De : Jaroslav Tulach <>
> > Envoyé : dimanche 3 juillet 2022 07:38 À : dev@netbeans.apache.org
> > Objet : Re: Bad links in javadoc
> >
> > If I run `ant build-javadoc` I get a file with ~2000 broken link reports:
> >
> > ```
> > netbeans$ cat nbbuild/build/javadoc/checklinks-errors.xml | wc -l
> > 1915
> > ```
> >
> > I do remember times when there were no broken links in Javadoc
> >
> > Ideally we fix the broken links, enable gate check to fail the build
> > if there is a broken link in the
> > `nbbuild/build/javadoc/checklinks-errors.xml`
> > file and then happily live forever.
> >
> >> PR is integrated only a month ago but the library needs to be released.
> > What PR are you talking about, Eric?
> >
> >> We also need to fix that for all NetBeans version from 12.6 to 14 +
> >> dev
> > NetBeans 12.6 has been released more than a month ago. Do we know what
> > caused the regression in broken links?
> >
> > -jt
> >
> >> -Message d'origine-
> >> De : Ernie Rael <>
> >> Envoyé : dimanche 19 juin 2022 15:51
> >> À : dev@netbeans.apache.org
> >> Objet : Bad links in javadoc
> >>
> >> I recall that someone had a doclet patch/PR to fix NetBeans javadoc,
> >> at least a few months ago I think. Was it ever integrated? Could it be?
> >>
> >> At
> >>
> >>
> >> https://bits.netbeans.org/dev/javadoc/org-openide-text/overview-summa
> >> r
> >> y.htm
> >> l
> >>
> >> if I click on
> >>
> >>  .../org/openide/text/doc-files/api.html
> >>
> >> <https://bits.netbeans.org/dev/javadoc/org-openide-text/org/openide/t
> >> e
> >> xt/do
> >> c-files/api.html>
> >>
> >> I end up at the "standing on our own feet" page.
> >>
> >> -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
> >
> >
> >
> >
> > -
> > 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
>
>
>
>
>
> -
> 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
>
>
>
>

[VOTE] NetBeans HTML/Java API 1.8.1

[Jaroslav Tulach]

Hi.
A bugfix release of HTML/Java API is needed. While trying to upgrade HTML/Java 
libraries in NetBeans/VSCode: https://github.com/apache/netbeans/pull/4040 - 
it has been found that additional bugfixes over 1.8 are needed.

This is the main voting artefact:
https://dist.apache.org/repos/dist/dev/netbeans/netbeans-html4j/netbeans-html4j-1.8.1/netbeans-html4j-1.8.1.zip
its sha512sum is 
6540380491059525eab26b8f331f7f7098acce33063237fb591ba5aba2c6b09be29ff51ac991971948ae57c74b86b32b6a09aa164b625f413ba9e2f7be9e8d2f
and I signed it as 
https://dist.apache.org/repos/dist/dev/netbeans/netbeans-html4j/netbeans-html4j-1.8.1/netbeans-html4j-1.8.1.zip.asc
 - these files were 
produced by https://ci-builds.apache.org/job/Netbeans/view/html4j/job/
netbeans-html4j-release/12/ job run.

If you want to build from the source, then unzip and use following command:

netbeans-html4j$ mvn clean install -DskipTests

you can also run the command without `-DskipTests` and report a (non blocking) 
test failure. Right now the tests seem to be stable, but historically they 
have been a bit flaky.

Of course, to verify the new library works, you should have an HTML/Java 
project and switch it to the new version. If you don't have such project, you 
can create one in NetBeans 13: "New Project/Java with Maven/Java Frontend 
Application" - if that application works for you, then you can switch to 
locally built HTML/Java API by changing:

--- a/pom.xml
+++ b/pom.xml
@@ -15,7 +15,7 @@
 js
 
 
-1.7
+1.8.1
 11
 1.0
 2.13

If your application continues to work, everything is OK.

In addition to the main voting artifact, we are also about to approve the 
following Maven repository:
https://repository.apache.org/content/repositories/orgapachenetbeans-1120/
It has been produced by unzipping the main ZIP file and running:
```
netbeans-html4j$ JAVA_HOME=/jdk-17/ mvn -Dgpg.keyname=xyz -Papache-release  
clean -DskipTests deploy
```
I'll release it to Maven central if our vote passes.

Please cast your votes. The vote is going to be open at least for 72h.
-jt








-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Bad links in javadoc

[Jaroslav Tulach]

If I run `ant build-javadoc` I get a file with ~2000 broken link reports:

```
netbeans$ cat nbbuild/build/javadoc/checklinks-errors.xml | wc -l
1915
```

I do remember times when there were no broken links in Javadoc

Ideally we fix the broken links, enable gate check to fail the build if there 
is a broken link in the `nbbuild/build/javadoc/checklinks-errors.xml` file and 
then happily live forever.

> PR is integrated only a month ago but the library needs to be released.

What PR are you talking about, Eric?
 
> We also need to fix that for all NetBeans version from 12.6 to 14 + dev

NetBeans 12.6 has been released more than a month ago. Do we know what caused 
the regression in broken links?

-jt

> -Message d'origine-
> De : Ernie Rael <>
> Envoyé : dimanche 19 juin 2022 15:51
> À : dev@netbeans.apache.org
> Objet : Bad links in javadoc
> 
> I recall that someone had a doclet patch/PR to fix NetBeans javadoc, at
> least a few months ago I think. Was it ever integrated? Could it be?
> 
> At
> 
>
> https://bits.netbeans.org/dev/javadoc/org-openide-text/overview-summary.htm
> l
> 
> if I click on
> 
> .../org/openide/text/doc-files/api.html
>
>  c-files/api.html>
> 
> I end up at the "standing on our own feet" page.
> 
> -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





-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Bad links in javadoc

[Jaroslav Tulach]

Dne neděle 19. června 2022 15:50:45 CEST, Ernie Rael napsal(a):
> I recall that someone had a doclet patch/PR to fix NetBeans javadoc, at
> least a few months ago I think. Was it ever integrated? Could it be?

I've also noticed
https://bits.netbeans.org/14/javadoc/org-openide-text/org/openide/text/doc-files/api.html#auto-ann
page is missing while
https://bits.netbeans.org/12.5/javadoc/org-openide-text/org/openide/text/doc-files/api.html#auto-ann
is present.

-jt

>
> https://bits.netbeans.org/dev/javadoc/org-openide-text/overview-summary.htm
> l
> 
> if I click on
> 
> .../org/openide/text/doc-files/api.html
>
>  c-files/api.html>
> 
> I end up at the "standing on our own feet" page.
> 
> -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: Netbeans module development

[Jaroslav Tulach]

Dne sobota 2. července 2022 12:55:14 CEST, Peter Cheung napsal(a):
> Hi
>  We are building the verilog plugin to display instructmentation data
> from verilator. Is there any API to highlight some rows in the editor and
> paint some text behind some specific lines?


For example: https://bits.netbeans.org/12.3/javadoc/org-openide-text/org/
openide/text/doc-files/api.html#auto-ann
-jt

Btw. The same page for NetBeans 14 Javadoc is missing: https://
bits.netbeans.org/14/javadoc/org-openide-text/org/openide/text/doc-files/
api.html#auto-ann



-
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: Generate javadoc for all modules from sources (not only the public ones)

[Jaroslav Tulach]

Dne sobota 11. června 2022 19:28:26 CEST, Jean-Marc Borer napsal(a):
> I may add that I cloned with version 13.0 as tag. So maybe I shall rephrase
> a bit: how can I generate the "DEV" like javadoc for a given source set?

```bash
netbeans$ JAVA_HOME=/jdk-11 ant build-javadoc
```

Seems to work for me.
-jt

> 
> On Sat, Jun 11, 2022 at 6:56 PM Jean-Marc Borer  wrote:
> > I mean the DEV javadoc
> > 
> > On Sat, Jun 11, 2022 at 6:36 PM Jean-Marc Borer  wrote:
> >> Hello,
> >> 
> >> Simple question actually, but I didn't manage to find the answer yet. I
> >> want to generate the same javadoc as you find on
> >> https://bits.netbeans.org/dev/javadoc/.
> >> 
> >> However when I run "ant javadoc" from the project (that I cloned
> >> previously), I only get the javadoc for the public modules. I miss the
> >> "hidden" ones like boostrap or "editor indentation".
> >> 
> >> Does anyone know the magic trick to generate that javadoc as well?
> >> 
> >> Thx in advance for your help.
> >> 
> >> Cheers,
> >> 
> >> JM





-
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: Kill ValidateLayerConsistencyTest?

[Jaroslav Tulach]

Removing unstable tests from CI is proper attitude.

There is a value in `ValidateLayerConsistencyTest` - the problems it detects 
(when working properly) would manifest themselves in incorrect runtime 
behavior.

Up to everyone to judge what is more valuable - stable CI or stable runtime? 
In this case I'd just restart the CI job, but I understand your frustration, 
Matthias.

> 2022-05-29T17:06:31.9092439Z [junit] java.lang.AssertionError: Has to be
> NbRepository: org.openide.filesystems.Repository@744b325b
> 2022-05-29T17:06:31.9093232Z [junit]  at
> org.netbeans.core.startup.Main.start(Main.java:298)
> 2022-05-29T17:06:31.9094120Z [junit]  at
> org.netbeans.core.startup.TopThreadGroup.run(TopThreadGroup.java:98)
> 2022-05-29T17:06:31.9094571Z [junit]  at
> java.lang.Thread.run(Thread.java:750) 2022-05-29T17:06:31.9095235Z
> [junit]

Isn't this caused by some race condition? Temporarily adding `this.when = new 
Exception("initialized")` into `Repository` constructor and printing the 
stacktraces when the `AssertionError` happens might tell us who's responsible 
for the misconfiguration of the test.
-jt


Dne neděle 29. května 2022 19:19:42 CEST, Matthias Bläsing napsal(a):
> Hi all,
> 
> for me the testing of NetBeans shows its ugly dark side and I'm
> seriously thinking about killing the ValidateLayerConsistencyTest. It
> is flaky and causes untraceable errors.
> 
> This is the PR:
> 
> https://github.com/apache/netbeans/pull/4058
> 
> The flakiness can be observed when comparing the commit validation
> runs. 1 fails whiel 3 work ok. In this instance the failing instance is
> JDK8, but I saw others.
> 
> I use this PR to try to fix this:
> 
> https://github.com/apache/netbeans/tree/try_fix_commit_validation2
> 
> One problem could be tracked down, that the maven module has a entry in
> the configuration, that is a template, but is checked for instablility.
> Fixed here:
> 
> https://github.com/apache/netbeans/commit/40a60e311000977b490935c6bf762464d3
> ddaa96
> 
> Currently it fails with an error that also seems to be a race condition
> (line 23766-2769):
> 
> https://pipelines.actions.githubusercontent.com/serviceHosts/3cf2747f-b5d6-4
> e8e-a999-150ff8ae61e1/_apis/pipelines/1/runs/14001/signedlogcontent/7?urlExp
> ires=2022-05-29T17%3A16%3A59.2143803Z&urlSigningMethod=HMACV1&urlSignature=f
> %2B%2BJVlE0n3fHCqA4wJkq4iKPdD%2B502hC2csZJFs5keE%3D
> 
> 2022-05-29T17:06:31.9092439Z [junit] java.lang.AssertionError: Has to be
> NbRepository: org.openide.filesystems.Repository@744b325b
> 2022-05-29T17:06:31.9093232Z [junit]  at
> org.netbeans.core.startup.Main.start(Main.java:298)
> 2022-05-29T17:06:31.9094120Z [junit]  at
> org.netbeans.core.startup.TopThreadGroup.run(TopThreadGroup.java:98)
> 2022-05-29T17:06:31.9094571Z [junit]  at
> java.lang.Thread.run(Thread.java:750) 2022-05-29T17:06:31.9095235Z
> [junit]
> ---
>  2022-05-29T17:06:31.9095602Z [junit] >Log Session: Sunday, May 29,
> 2022 5:06:31 PM UTC 2022-05-29T17:06:31.9095875Z [junit] >System Info:
> 2022-05-29T17:06:31.9096375Z [junit]   Product Version = Apache
> NetBeans Platform Dev (Build dev-40a60e311000977b490935c6bf762464d3ddaa96)
> 
> Given that I changed code in the JS area, this does not seem to related
> to my changes.
> 
> So at this point this Test does harm and so is a candidate to be
> removed.
> 
> I would like to fix this tough, but I put literally days into this and
> am at the end of my ideas. Anyone wants to chime in?
> 
> 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: [CANCEL][VOTE] Release Apache Netbeans Standalone Java Hints Tool 13.0 [vote candidate 1]

[Jaroslav Tulach]

Dne pondělí 6. června 2022 7:39:07 CEST, Jan Lahoda napsal(a):
> Hi,
> 
> Should all be fixed. Please note that to fail the build, one should ask for
> that in the pom.xml using "failOnWarnings" like here:
> https://github.com/apache/netbeans-jackpot30/blob/db82ffa0d6aae6d18545f5a6ef
> fe44cfaeff3fbb/cmdline/maven/tests/fail-on-warnings/pom.xml#L50

Is introduction of `` result of "compatibility first" 
attitude? While I am all for compatibility I don't understand what is the 
purpose of `mvn jackpot30:analyze` when it doesn't fail!

-jt

> On Tue, May 24, 2022 at 11:50 AM Jaroslav Tulach 
> wrote:
> > This is a fix for the version selection. Don't we also need a fix that
> > would fail the build?
> > -jt
> > 
> > Dne út 24. 5. 2022 7:35 uživatel Jan Lahoda  napsal:
> > > Oops. Fix:
> > > https://github.com/apache/netbeans-jackpot30/pull/26
> > > 
> > > Please review.
> > > 
> > > Thanks for testing!
> > > 
> > > Jan
> > > 
> > > On Mon, May 23, 2022 at 7:54 AM Jaroslav Tulach <
> > 
> > jaroslav.tul...@gmail.com
> > 
> > > wrote:
> > > > -1
> > > > 
> > > > Maybe I don't understand how to use Jackpot properly, but if I try:
> > > > 
> > > > ```
> > > > netbeans-html4j$ git diff
> > > > diff --git a/json-tck/pom.xml b/json-tck/pom.xml
> > > > index 68242488..8b15e154 100644
> > > > --- a/json-tck/pom.xml
> > > > +++ b/json-tck/pom.xml
> > > > @@ -58,7 +58,9 @@
> > > > 
> > > >
> > > >
> > > >org.apache.netbeans.modules.jackpot30 > > >>
> > > >jackpot30-maven-plugin
> > > > 
> > > > -  12.3
> > > > +  13.0
> > > > +  
> > > > +  
> > > > 
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > 
> > > > ```
> > > > 
> > > > and then run:
> > > > ```
> > > > netbeans-html4j$ mvn clean install -DskipTests
> > > > netbeans-html4j$ mvn -f json-tck/ jackpot30:analyze
> > > > --- jackpot30-maven-plugin:13.0:analyze (default-cli) @
> > > > net.java.html.json.tck
> > > > unrecognized source level specification: 17
> > > > BUILD SUCCESS
> > > > ``
> > > > 
> > > > #1 - I am not sure why it cannot recognize source level 17
> > > > #2 - I don't understand why it prints "BUILD SUCCESS"
> > > > #3 - it certainly doesn't detect any errors[1]
> > > > 
> > > > -jt
> > > > 
> > > > [1] The "warning" that IDE detects properly, but `jackpot30:analyze`
> > > > doesn't:
> > > > 
> > > > --- a/json-tck/src/main/java/net/java/html/js/tests/JsUtils.java
> > > > +++ b/json-tck/src/main/java/net/java/html/js/tests/JsUtils.java
> > > > @@ -19,13 +19,17 @@
> > > > 
> > > >  package net.java.html.js.tests;
> > > >  
> > > >  import java.io.StringReader;
> > > > 
> > > > +import java.util.ArrayList;
> > > > 
> > > >  import java.util.ServiceLoader;
> > > >  import net.java.html.json.Models;
> > > >  import org.netbeans.html.boot.spi.Fn;
> > > >  import org.netbeans.html.json.tck.JavaScriptTCK;
> > > >  
> > > >  public class JsUtils {
> > > > 
> > > > +
> > > > +private final ArrayList list;
> > > > 
> > > >  private JsUtils() {
> > > > 
> > > > +list = new ArrayList<>();
> > > > 
> > > >  }
> > > >  
> > > >  private static JavaScriptTCK instantiatedJsTCK;
> > > > 
> > > > Dne neděle 22. května 2022 9:12:10 CEST, Jan Lahoda napsal(a):
> > > > > Dear all,
> > > > > 
> > > > > I'd like to release the standalone Java Hints tool ("jackpot") based
> > 
> > on
> > 
> > > > > Apache NetBeans 13.0, including the nb-javac.
> > 
> > > > > The release is here:
> > https://dist.apache.org/repos/dist/dev/netbeans/netbeans-jackpot/netbeans-> 
> > > ja> 
> 

Re: [LAZY CONSENSUS] Reorganize maven-utilities repository into one

[Jaroslav Tulach]

Dne pátek 3. června 2022 16:19:37 CEST, Neil C Smith napsal(a):
> On Fri, 3 Jun 2022, 13:59 antonio,  wrote:
> > The "BOM" (Bill of Materials) is a  packaging that "defines the
> > versions of all the artifacts that will be created in the library. ...
> > 
> > So basically this will be a pom.xml with pom that
> > list all other module dependencies.
> > 
> > I don't think it's of any use if you want to build NetBeans Platform
> > based apps, as we already have a sound Maven based solution.
> 
> Actually there was a brief discussion a while ago about whether we could
> use a BOM with clusters, etc. so that we could publish modules using their
> spec version. That way we might push updates for individual modules without
> needing to republish a whole release.

Yes, having BOM for clusters would be great. For reference: https://
lists.apache.org/thread/xqf041nzhl1rwvh4gosqkg19h43g9fl6
-jt




-
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: [CANCEL][VOTE] Release Apache Netbeans Standalone Java Hints Tool 13.0 [vote candidate 1]

[Jaroslav Tulach]

This is a fix for the version selection. Don't we also need a fix that
would fail the build?
-jt


Dne út 24. 5. 2022 7:35 uživatel Jan Lahoda  napsal:

> Oops. Fix:
> https://github.com/apache/netbeans-jackpot30/pull/26
>
> Please review.
>
> Thanks for testing!
>
> Jan
>
> On Mon, May 23, 2022 at 7:54 AM Jaroslav Tulach  >
> wrote:
>
> > -1
> >
> > Maybe I don't understand how to use Jackpot properly, but if I try:
> >
> > ```
> > netbeans-html4j$ git diff
> > diff --git a/json-tck/pom.xml b/json-tck/pom.xml
> > index 68242488..8b15e154 100644
> > --- a/json-tck/pom.xml
> > +++ b/json-tck/pom.xml
> > @@ -58,7 +58,9 @@
> >
> >org.apache.netbeans.modules.jackpot30
> >jackpot30-maven-plugin
> > -  12.3
> > +  13.0
> > +  
> > +  
> >
> >
> >
> > ```
> >
> > and then run:
> > ```
> > netbeans-html4j$ mvn clean install -DskipTests
> > netbeans-html4j$ mvn -f json-tck/ jackpot30:analyze
> > --- jackpot30-maven-plugin:13.0:analyze (default-cli) @
> > net.java.html.json.tck
> > unrecognized source level specification: 17
> > BUILD SUCCESS
> > ``
> >
> > #1 - I am not sure why it cannot recognize source level 17
> > #2 - I don't understand why it prints "BUILD SUCCESS"
> > #3 - it certainly doesn't detect any errors[1]
> >
> > -jt
> >
> > [1] The "warning" that IDE detects properly, but `jackpot30:analyze`
> > doesn't:
> >
> > --- a/json-tck/src/main/java/net/java/html/js/tests/JsUtils.java
> > +++ b/json-tck/src/main/java/net/java/html/js/tests/JsUtils.java
> > @@ -19,13 +19,17 @@
> >  package net.java.html.js.tests;
> >
> >  import java.io.StringReader;
> > +import java.util.ArrayList;
> >  import java.util.ServiceLoader;
> >  import net.java.html.json.Models;
> >  import org.netbeans.html.boot.spi.Fn;
> >  import org.netbeans.html.json.tck.JavaScriptTCK;
> >
> >  public class JsUtils {
> > +
> > +private final ArrayList list;
> >  private JsUtils() {
> > +list = new ArrayList<>();
> >  }
> >
> >  private static JavaScriptTCK instantiatedJsTCK;
> >
> > Dne neděle 22. května 2022 9:12:10 CEST, Jan Lahoda napsal(a):
> > > Dear all,
> > >
> > > I'd like to release the standalone Java Hints tool ("jackpot") based on
> > > Apache NetBeans 13.0, including the nb-javac.
> > >
> > > The release is here:
> > >
> >
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-jackpot/netbeans-ja
> > > ckpot-13.0-vc1/apache-netbeans-jackpot-13.0.zip
> > >
> > > Signature file:
> > >
> >
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-jackpot/netbeans-ja
> > > ckpot-13.0-vc1/apache-netbeans-jackpot-13.0.zip.asc
> > >
> > > SHA512:
> > >
> >
> 7c1bf5e57a550791e2c9ca56578ce62c403bd6d2cae580a55cae09ad54b3002a990e05a23a5a
> > > 337268b22141e57c7b1073644a1dd5c0f630592da070295bbcf9
> > > apache-netbeans-jackpot-13.0.zip
> > >
> > > KEYS file:
> > >
> > > https://dist.apache.org/repos/dist/release/netbeans/KEYS
> > >
> > > Apache NetBeans Jackpot 3.0 Git Repo tag:
> > >
> >
> https://github.com/apache/netbeans-jackpot30/releases/tag/netbeans-jackpot-1
> > > 3.0-vc1
> > >
> > > Convenience binaries:
> > > -built standalone tool:
> > >
> >
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-jackpot/netbeans-ja
> > > ckpot-13.0-vc1/apache-netbeans-jackpot-13.0-bin.zip
> > >
> > > Its signature file:
> > >
> >
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-jackpot/netbeans-ja
> > > ckpot-13.0-vc1/apache-netbeans-jackpot-13.0-bin.zip.asc
> > >
> > > and its SHA512:
> > >
> >
> 3746cc0ae84ed61395db7c254254476d451f96366789feb2a02e92b630c6ea2e150baa1c7190
> > > f089e1b259319191d08a302211c47e648615b4b130de7cb9b036
> > > apache-netbeans-jackpot-13.0-bin.zip
> > >
> > > -there is also a plugin staging Maven repository here:
> > >
> >
> https://repository.apache.org/content/repositories/orgapachenetbeans-1112/
> > >
> > > This vote is going to be open at least 72 hours, please vote with +1,
> 0,
> > > and -1 as usual.
> > >
> > > Thanks for any feedback!
> > >
> > > Jan
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> > For additional commands, e-mail: dev-h...@netbeans.apache.org
> >
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >
> >
> >
> >
>

Re: [VOTE] Release Apache Netbeans Standalone Java Hints Tool 13.0 [vote candidate 1]

[Jaroslav Tulach]

-1

Maybe I don't understand how to use Jackpot properly, but if I try:

```
netbeans-html4j$ git diff
diff --git a/json-tck/pom.xml b/json-tck/pom.xml
index 68242488..8b15e154 100644
--- a/json-tck/pom.xml
+++ b/json-tck/pom.xml
@@ -58,7 +58,9 @@
   
   org.apache.netbeans.modules.jackpot30
   jackpot30-maven-plugin
-  12.3
+  13.0
+  
+  
   
   
   
```

and then run:
```
netbeans-html4j$ mvn clean install -DskipTests
netbeans-html4j$ mvn -f json-tck/ jackpot30:analyze
--- jackpot30-maven-plugin:13.0:analyze (default-cli) @ net.java.html.json.tck 
unrecognized source level specification: 17
BUILD SUCCESS
``

#1 - I am not sure why it cannot recognize source level 17
#2 - I don't understand why it prints "BUILD SUCCESS"
#3 - it certainly doesn't detect any errors[1]

-jt

[1] The "warning" that IDE detects properly, but `jackpot30:analyze` doesn't:

--- a/json-tck/src/main/java/net/java/html/js/tests/JsUtils.java
+++ b/json-tck/src/main/java/net/java/html/js/tests/JsUtils.java
@@ -19,13 +19,17 @@
 package net.java.html.js.tests;
 
 import java.io.StringReader;
+import java.util.ArrayList;
 import java.util.ServiceLoader;
 import net.java.html.json.Models;
 import org.netbeans.html.boot.spi.Fn;
 import org.netbeans.html.json.tck.JavaScriptTCK;
 
 public class JsUtils {
+
+private final ArrayList list;
 private JsUtils() {
+list = new ArrayList<>();
 }
 
 private static JavaScriptTCK instantiatedJsTCK;

Dne neděle 22. května 2022 9:12:10 CEST, Jan Lahoda napsal(a):
> Dear all,
> 
> I'd like to release the standalone Java Hints tool ("jackpot") based on
> Apache NetBeans 13.0, including the nb-javac.
> 
> The release is here:
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-jackpot/netbeans-ja
> ckpot-13.0-vc1/apache-netbeans-jackpot-13.0.zip
> 
> Signature file:
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-jackpot/netbeans-ja
> ckpot-13.0-vc1/apache-netbeans-jackpot-13.0.zip.asc
> 
> SHA512:
> 7c1bf5e57a550791e2c9ca56578ce62c403bd6d2cae580a55cae09ad54b3002a990e05a23a5a
> 337268b22141e57c7b1073644a1dd5c0f630592da070295bbcf9
> apache-netbeans-jackpot-13.0.zip
> 
> KEYS file:
> 
> https://dist.apache.org/repos/dist/release/netbeans/KEYS
> 
> Apache NetBeans Jackpot 3.0 Git Repo tag:
> https://github.com/apache/netbeans-jackpot30/releases/tag/netbeans-jackpot-1
> 3.0-vc1
> 
> Convenience binaries:
> -built standalone tool:
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-jackpot/netbeans-ja
> ckpot-13.0-vc1/apache-netbeans-jackpot-13.0-bin.zip
> 
> Its signature file:
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-jackpot/netbeans-ja
> ckpot-13.0-vc1/apache-netbeans-jackpot-13.0-bin.zip.asc
> 
> and its SHA512:
> 3746cc0ae84ed61395db7c254254476d451f96366789feb2a02e92b630c6ea2e150baa1c7190
> f089e1b259319191d08a302211c47e648615b4b130de7cb9b036
> apache-netbeans-jackpot-13.0-bin.zip
> 
> -there is also a plugin staging Maven repository here:
> https://repository.apache.org/content/repositories/orgapachenetbeans-1112/
> 
> This vote is going to be open at least 72 hours, please vote with +1, 0,
> and -1 as usual.
> 
> Thanks for any feedback!
> 
> Jan





-
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] 14 remaining issues

[Jaroslav Tulach]

Dne sobota 21. května 2022 10:34:35 CEST, Neil C Smith napsal(a):
> On Sat, 21 May 2022, 09:10 Jaroslav Tulach, 
> 
> wrote:
> > > IMO it's hard to see how any of the sampler PRs meet the general
> > > requirements for merges to delivery. Do we really need to push back the
> > 
> > IDE
> > 
> > > release a week on this?
> > 
> > I don't know. That is a decision for release coordinators.
> 
> No, it isn't! It's up to the PR author (you) and then the whole community
> (via review) to make that call. 

I made the call. I created the PR. Community approved it - e.g. it is good 
enough from a technical point of view, but...

> The release team doesn't decide what needs
> merging.

...but when I studied the `delivery` rules the last time, the #1 rule was: No 
mere developer can press the merge button - a release coordinator has to. If 
the rule still applies, then it is the release team who ultimately decides 
what to merge into `delivery` (and I am fine with that). 

> > > What high / critical priority issue on our side is
> > > addressed?
> > 
> > The sampler JAR cannot be used in headless environment right now due to
> > call
> > to `SwingUtilities.isEventDispatchThread()` which PR-4134 removes.
> 
> Isn't use in a headless environment a new feature that didn't exist at
> feature freeze? Or was it always meant to support headless and was broken
> at some point?

Some form of headless/CLI sampling was always there https://github.com/apache/
netbeans/blob/862379894fc239268e55f00bb4ce337d4c4437b8/platform/sampler/src/
org/netbeans/modules/sampler/CLISampler.java#L46 since the creation of the 
module. I knew about it and we are trying to use it - but our use is 
"different" and reveals various limitations in the original code.

-jt




-
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] 14 remaining issues

[Jaroslav Tulach]

Dne pátek 20. května 2022 15:48:41 CEST, Neil C Smith napsal(a):
> On Fri, 20 May 2022, 13:27 Jaroslav Tulach, 
> 
> wrote:
> > Dne čtvrtek 19. května 2022 17:02:41 CEST, Eric Barboni napsal(a):
> > > Hi,
> > > I see no new issue on NB14 so maybe it would be ok to build a voting
> > > candidate on Friday ? Or postpone until Monday if tester needs more
> > > time?
> > 
> > I'd be thankful for integrating yet more fix https://github.com/apache/
> > netbeans/pull/4134 <https://github.com/apache/netbeans/pull/4134> in the
> > sampler.
> 
> IMO it's hard to see how any of the sampler PRs meet the general
> requirements for merges to delivery. Do we really need to push back the IDE
> release a week on this? 

I don't know. That is a decision for release coordinators.

> What high / critical priority issue on our side is
> addressed?

The sampler JAR cannot be used in headless environment right now due to call 
to `SwingUtilities.isEventDispatchThread()` which PR-4134 removes.
-jt




-
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] 14 remaining issues

[Jaroslav Tulach]

The only thing I care about is: once the bits appear on Maven central, they 
are usable for us.
-jt

Dne pátek 20. května 2022 15:18:26 CEST, Eric Barboni napsal(a):
> Hi why not,
> I was about to start the process but I can wait.
> Just this will need RC5
> 
> Would be good to be ready for Monday voting candidate and having some vote
> to prepare vsis macos windows installer with allready binding vote.
> 
> Next week is partialy cut by public holidays not sure to have computer end
> of the next week.
> 
> Regards
> Eric
> -Message d'origine-
> De : Jaroslav Tulach <>
> Envoyé : vendredi 20 mai 2022 14:27
> À : dev@netbeans.apache.org
> Objet : Re: [RELEASES] 14 remaining issues
> 
> Dne čtvrtek 19. května 2022 17:02:41 CEST, Eric Barboni napsal(a):
> > Hi,
> > I see no new issue on NB14 so maybe it would be ok to build a voting
> > candidate on Friday ? Or postpone until Monday if tester needs more time?
> 
> I'd be thankful for integrating yet more fix https://github.com/apache/
> netbeans/pull/4134 in the sampler.
> -jt
> 
> > -Message d'origine-
> > De : Antonio Vieiro <>
> > Envoyé : jeudi 12 mai 2022 15:49
> > À : dev 
> > Objet : Re: [RELEASES] 14 remaining issues
> > 
> > Can't tell, really. I think I deleted a dependency in a Maven project,
> > and then it happened.
> > 
> > Will try to take a look at it in the evening.
> > 
> > El jue, 12 may 2022 a las 14:32, Eric Barboni ()
> 
> escribió:
> > > Hi
> > > 
> > >  What was your actions that lead to this ? I have windows 11 and I
> > > 
> > > don't  see this issue.> Some issue on the jenkins build seems to be
> > > related to Stamps since a long time (709 builds).
> > > https://ci-builds.apache.org/job/Netbeans/job/netbeans-windows/lastC
> > > om
> > > pletedBuild/testReport/
> > > 
> > > But it has to be locally recompiled as we have not archived the
> > > result folder.
> > > 
> > > https://github.com/apache/netbeans/pull/4096
> > > 
> > > Best Regards
> > > Eric
> > > -Message d'origine-
> > > De : Antonio Vieiro <>
> > > Envoyé : jeudi 12 mai 2022 11:34
> > > À : dev 
> > > Objet : Re: [RELEASES] 14 remaining issues
> > > 
> > > Hi all,
> > > 
> > > I'm seeing this [1] in NB14-RC3 on a Windows 10 box. It seems we're
> > > stubborn trying to delete "all-layers.dat".
> > > 
> > > Is this a known issue? Blocker?
> > > 
> > > Thanks
> > > Antonio
> > > 
> > > 
> > > INFO [org.netbeans.Stamps]: after GC INFO [org.netbeans.Stamps]:
> > > Slept 426 ms WARNING
> > > [org.netbeans.Stamps]: Error saving cache
> > > C:\Users\USER\AppData\Local\NetBeans\Cache\14-rc3\all-layers.dat
> > > INFO [org.netbeans.Stamps]: Could not delete:
> > > C:\Users\USER\AppData\Local\NetBeans\Cache\14-rc3\all-layers.dat
> > > java.io.IOException: Could not delete:
> > > C:\Users\USER\AppData\Local\NetBeans\Cache\14-rc3\all-layers.dat
> > > 
> > > at org.netbeans.Stamps.deleteCache(Stamps.java:505)
> > > at org.netbeans.Stamps.access$200(Stamps.java:68)
> > > 
> > > [catch] at org.netbeans.Stamps$Store.store(Stamps.java:699)
> > > 
> > > at org.netbeans.Stamps$Worker.run(Stamps.java:877)
> > > 
> > > INFO [org.netbeans.Stamps]: cannot rename (#0):
> > > C:\Users\USER\AppData\Local\NetBeans\Cache\14-rc3\all-layers.dat
> > > INFO [org.netbeans.Stamps]: after GC INFO [org.netbeans.Stamps]:
> > > Slept 918 ms INFO [org.netbeans.Stamps]:
> > > cannot rename (#1):
> > > C:\Users\USER\AppData\Local\NetBeans\Cache\14-rc3\all-layers.dat
> > > INFO [org.netbeans.Stamps]: after GC INFO [org.netbeans.Stamps]:
> > > Slept 530 ms INFO [org.netbeans.Stamps]:
> > > cannot rename (#2):
> > > C:\Users\USER\AppData\Local\NetBeans\Cache\14-rc3\all-layers.dat
> > > INFO [org.netbeans.Stamps]: after GC INFO [org.netbeans.Stamps]:
> > > Slept 383 ms INFO [org.netbeans.Stamps]:
> > > cannot rename (#3):
> > > C:\Users\USER\AppData\Local\NetBeans\Cache\14-rc3\all-layers.dat
> > > INFO [org.netbeans.Stamps]: after GC INFO [org.netbeans.Stamps]:
> > > Slept 13 ms INFO [org.netbeans.Stamps]:
> > > cannot rename (#4):
> > > C:\Users\USER\AppData\Local\NetBeans\Cache\14-rc3\all-layers.dat
> > > INFO [org.netbeans.Sta

Re: [RELEASES] 14 remaining issues

[Jaroslav Tulach]

Dne čtvrtek 19. května 2022 17:02:41 CEST, Eric Barboni napsal(a):
> Hi,
> I see no new issue on NB14 so maybe it would be ok to build a voting
> candidate on Friday ? Or postpone until Monday if tester needs more time?

I'd be thankful for integrating yet more fix https://github.com/apache/
netbeans/pull/4134 in the sampler. 
-jt

> -Message d'origine-
> De : Antonio Vieiro <>
> Envoyé : jeudi 12 mai 2022 15:49
> À : dev 
> Objet : Re: [RELEASES] 14 remaining issues
> 
> Can't tell, really. I think I deleted a dependency in a Maven project, and
> then it happened.
> 
> Will try to take a look at it in the evening.
> 
> El jue, 12 may 2022 a las 14:32, Eric Barboni () 
escribió:
> > Hi
> > 
> >  What was your actions that lead to this ? I have windows 11 and I don't
> >  see this issue.> 
> > Some issue on the jenkins build seems to be related to Stamps since a long
> > time (709 builds).
> > https://ci-builds.apache.org/job/Netbeans/job/netbeans-windows/lastCom
> > pletedBuild/testReport/
> > 
> > But it has to be locally recompiled as we have not archived the result
> > folder.
> > 
> > https://github.com/apache/netbeans/pull/4096
> > 
> > Best Regards
> > Eric
> > -Message d'origine-
> > De : Antonio Vieiro <>
> > Envoyé : jeudi 12 mai 2022 11:34
> > À : dev 
> > Objet : Re: [RELEASES] 14 remaining issues
> > 
> > Hi all,
> > 
> > I'm seeing this [1] in NB14-RC3 on a Windows 10 box. It seems we're
> > stubborn trying to delete "all-layers.dat".
> > 
> > Is this a known issue? Blocker?
> > 
> > Thanks
> > Antonio
> > 
> > 
> > INFO [org.netbeans.Stamps]: after GC
> > INFO [org.netbeans.Stamps]: Slept 426 ms WARNING
> > [org.netbeans.Stamps]: Error saving cache
> > C:\Users\USER\AppData\Local\NetBeans\Cache\14-rc3\all-layers.dat
> > INFO [org.netbeans.Stamps]: Could not delete:
> > C:\Users\USER\AppData\Local\NetBeans\Cache\14-rc3\all-layers.dat
> > java.io.IOException: Could not delete:
> > C:\Users\USER\AppData\Local\NetBeans\Cache\14-rc3\all-layers.dat
> > 
> > at org.netbeans.Stamps.deleteCache(Stamps.java:505)
> > at org.netbeans.Stamps.access$200(Stamps.java:68)
> > 
> > [catch] at org.netbeans.Stamps$Store.store(Stamps.java:699)
> > 
> > at org.netbeans.Stamps$Worker.run(Stamps.java:877)
> > 
> > INFO [org.netbeans.Stamps]: cannot rename (#0):
> > C:\Users\USER\AppData\Local\NetBeans\Cache\14-rc3\all-layers.dat
> > INFO [org.netbeans.Stamps]: after GC
> > INFO [org.netbeans.Stamps]: Slept 918 ms INFO [org.netbeans.Stamps]:
> > cannot rename (#1):
> > C:\Users\USER\AppData\Local\NetBeans\Cache\14-rc3\all-layers.dat
> > INFO [org.netbeans.Stamps]: after GC
> > INFO [org.netbeans.Stamps]: Slept 530 ms INFO [org.netbeans.Stamps]:
> > cannot rename (#2):
> > C:\Users\USER\AppData\Local\NetBeans\Cache\14-rc3\all-layers.dat
> > INFO [org.netbeans.Stamps]: after GC
> > INFO [org.netbeans.Stamps]: Slept 383 ms INFO [org.netbeans.Stamps]:
> > cannot rename (#3):
> > C:\Users\USER\AppData\Local\NetBeans\Cache\14-rc3\all-layers.dat
> > INFO [org.netbeans.Stamps]: after GC
> > INFO [org.netbeans.Stamps]: Slept 13 ms INFO [org.netbeans.Stamps]:
> > cannot rename (#4):
> > C:\Users\USER\AppData\Local\NetBeans\Cache\14-rc3\all-layers.dat
> > INFO [org.netbeans.Stamps]: after GC
> > 
> > El mié, 11 may 2022 a las 18:56, Laszlo Kishalmi
> > 
> > () escribió:
> > > Just updating the list here.
> > > 
> > > It is scheduled for NB15, not a blocker issue.
> > > 
> > > On 5/10/22 06:05, Eric Barboni wrote:
> > > > Hi,
> > > > 
> > > > Thanks to tester we found a regression and a fix is inbound.
> > > > 
> > > > There is a remaing issue 😝 (mine 😃) that seems not happening on
> > > > linux. If someone can test on windows it would be nice otherwise
> > > > this could be postponed to version 15
> > > > https://github.com/apache/netbeans/issues/4084
> > > > 
> > > > Best Regards
> > > > Eric
> > > > -Message d'origine-
> > > > De : Eric Barboni <>
> > > > Envoyé : jeudi 5 mai 2022 11:11
> > > > À : dev@netbeans.apache.org
> > > > Objet : RE: [RELEASES] 14- RC3 preparation
> > > > 
> > > > Hi,
> > > > 
> > > >   I will generate the RC3 after the #4047 get green (more or less).
> > > > 
> > > > RC3 contains the 2 unmerged PR of RC2. I reapply Martin Entlicher work
> > > > using a PR I created with diff file from PR 4004. Hope is good
> > > > enough.
> > > > 
> > > > As netbeans parent was release I will regenerate the RELEASE140
> > > > staging to be able to test artefacts.
> > > > 
> > > > Best Regards
> > > > 
> > > > Eric
> > > > 
> > > > -Message d'origine-
> > > > De : Michael Bien <>
> > > > Envoyé : mardi 3 mai 2022 18:50
> > > > À : dev@netbeans.apache.org; Eric Barboni  Objet :
> > > > Re: [RELEASES] Issue on delivery merge
> > > > 
> > > > On 03.05.22 18:28, Michael Bien wrote:
> > > >> or:
> > > >> 
> > > >> I (or anybody else) could also simply create another PR, from the
> > > >> original PR branch and we could just review + press merge again?
> > > > 
> > > > here a draf

[RESULT] [VOTE] NetBeans HTML/Java API 1.8

[Jaroslav Tulach]

HTML/Java release 1.8 has been approved. Thank you.

+4 (binding) - Dušan, Eric, Martin & me
+1 - Kai

Let's release the bits!
-jt


Dne neděle 15. května 2022 16:37:06 CEST, Jaroslav Tulach napsal(a):
> Hi.
> major improvements (introduction of `wait4java=false`) have been made in
> HTML/ Java API and it is time to release new version. Please help me by
> casting your votes.
> 
> This is the main voting artefact:
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-html4j/netbeans-htm
> l4j-1.8/netbeans-html4j-1.8.zip its sha512sum is
> a27af12057a588c2a232b695ef15ee573381a1356a2dcb632008ac4485d36ca7427228684b4e
> 757ecf50231c3d5e23eb92422a9de90338d0233184b79d04626b and I signed it as
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-html4j/netbeans-ht
> ml4j-1.8/netbeans-html4j-1.8.zip.asc - these files were produced by
> https://ci-builds.apache.org/job/Netbeans/job/netbeans-html4j-release/11/
> job run.
> 
> If you want to build from the source, then unzip and use following command:
> 
> netbeans-html4j$ mvn clean install -DskipTests
> 
> you can also run the command without `-DskipTests`, but on some
> configurations, some of the tests are flaky, so your outcome may vary. I am
> often receiving test failures in `browser` module and I have to re-run the
> tests few times.
> 
> Of course, to verify the new library works, you should have an HTML/Java
> project and switch it to the new version. If you don't have such project,
> you can create one in NetBeans 13: "New Project/Java with Maven/Java
> Frontend Application" - if that application works for you, then you can
> switch to locally built HTML/Java API by changing:
> 
> --- a/pom.xml
> +++ b/pom.xml
> @@ -15,7 +15,7 @@
>  js
>  
>  
> -1.7
> +1.8
>  11
>  1.0
>  2.13
> 
> If your application continues to work, everything is OK.
> 
> In addition to the main voting artifact, we are also about to approve the
> following Maven repository:
> https://repository.apache.org/content/repositories/orgapachenetbeans-
> It has been produced by unzipping the main ZIP file and running:
> ```
> netbeans-html4j$ JAVA_HOME=/jdk-17/ mvn -Dgpg.keyname=xyz -Papache-release
> clean -DskipTests deploy
> ```
> I'll release it to Maven central if our vote passes.
> 
> Please cast your votes. The vote is going to be open at least for 72h.
> -jt





-
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: How to disable GraalVM debugger?

[Jaroslav Tulach]

When one runs NetBeans on GraalVM, a "bubble" is shown asking whether to 
activate `node` from the GraalVM. If agreed, then the `node` execution shall 
happen on GraalVM's node implementation - including debugging with the JVM.

If one is using non-GraalVM's node, then the special GraalVM node support 
shall be inactive (apparently it is not).

CCing Martin.
-jt


Dne středa 18. května 2022 20:23:02 CEST, Matthias Bläsing napsal(a):
> Hi,
> 
> I wanted to try to fix the NodeJS Debugger and noticed, that the
> GraalVM support squats over it. It is a bit surprising, that on a
> NodeJS it is assumed, that I want to start GraalVM.
> 
> Given, that the common runtime for JS code in Web development and also
> backend development is node, I assume, that this should get priority.
> Before I begin to work on removing GraalVM from this, how was this
> planned to work out or was nodeJS support just ignored?
> 
> This is what I saw:
> 
> "/usr/bin/node"
> "--jvm.agentlib:jdwp=transport=dt_socket,address=44067,server=n,suspend=y"
> "/home/matthias/tmp/NodeJsApplication/main.js"
> 
> Seeing jvm parameters on a node invocation is IMHO a corner case.
> 
> 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: [VOTE] NetBeans HTML/Java API 1.8

[Jaroslav Tulach]

+1 (binding)

Verified on my Mac. SHA is OK, signature seems OK too. ZIP builds with JDK-8. 
Tests run except one or two failing tests in the `browser` project (as 
expected).

Dne neděle 15. května 2022 16:37:06 CEST, Jaroslav Tulach napsal(a):
> Hi.
> major improvements (introduction of `wait4java=false`) have been made in
> HTML/ Java API and it is time to release new version. Please help me by
> casting your votes.
> 
> This is the main voting artefact:
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-html4j/netbeans-htm
> l4j-1.8/netbeans-html4j-1.8.zip its sha512sum is
> a27af12057a588c2a232b695ef15ee573381a1356a2dcb632008ac4485d36ca7427228684b4e
> 757ecf50231c3d5e23eb92422a9de90338d0233184b79d04626b and I signed it as
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-html4j/netbeans-ht
> ml4j-1.8/netbeans-html4j-1.8.zip.asc - these files were produced by
> https://ci-builds.apache.org/job/Netbeans/job/netbeans-html4j-release/11/
> job run.
> 
> If you want to build from the source, then unzip and use following command:
> 
> netbeans-html4j$ mvn clean install -DskipTests
> 
> you can also run the command without `-DskipTests`, but on some
> configurations, some of the tests are flaky, so your outcome may vary. I am
> often receiving test failures in `browser` module and I have to re-run the
> tests few times.
> 
> Of course, to verify the new library works, you should have an HTML/Java
> project and switch it to the new version. If you don't have such project,
> you can create one in NetBeans 13: "New Project/Java with Maven/Java
> Frontend Application" - if that application works for you, then you can
> switch to locally built HTML/Java API by changing:
> 
> --- a/pom.xml
> +++ b/pom.xml
> @@ -15,7 +15,7 @@
>  js
>  
>  
> -1.7
> +1.8
>  11
>  1.0
>  2.13
> 
> If your application continues to work, everything is OK.
> 
> In addition to the main voting artifact, we are also about to approve the
> following Maven repository:
> https://repository.apache.org/content/repositories/orgapachenetbeans-
> It has been produced by unzipping the main ZIP file and running:
> ```
> netbeans-html4j$ JAVA_HOME=/jdk-17/ mvn -Dgpg.keyname=xyz -Papache-release
> clean -DskipTests deploy
> ```
> I'll release it to Maven central if our vote passes.
> 
> Please cast your votes. The vote is going to be open at least for 72h.
> -jt





-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: [VOTE] NetBeans HTML/Java API 1.8

[Jaroslav Tulach]

Dne pondělí 16. května 2022 10:33:13 CEST, Eric Barboni napsal(a):
> Hi
> It seems
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-html4j/netbeans-htm
> l4j-1.8/netbeans-html4j-1.8.zip.asc is not valid to me.
> Checked a few maven artefacts and they are signed ok but not the zip on
> dist.
> 
> gpg:using DSA key BC2F371DABCE5C3BC962E8ACBCE39E6510A1BE04
> gpg: Can't check signature: No public key

Thank you Eric for spotting this problem. Updated in revision 54556. I hope 
the .asc file is now correct and the vote can go on.
-jt

> -Message d'origine-
> De : Jaroslav Tulach <>
> Envoyé : dimanche 15 mai 2022 16:37
> À : dev@netbeans.apache.org
> Objet : [VOTE] NetBeans HTML/Java API 1.8
> 
> Hi.
> major improvements (introduction of `wait4java=false`) have been made in
> HTML/ Java API and it is time to release new version. Please help me by
> casting your votes.
> 
> This is the main voting artefact:
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-html4j/netbeans-htm
> l4j-1.8/netbeans-html4j-1.8.zip
> its sha512sum is
> a27af12057a588c2a232b695ef15ee573381a1356a2dcb632008ac4485d36ca7427228684b4e
> 757ecf50231c3d5e23eb92422a9de90338d0233184b79d04626b
> and I signed it as
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-html4j/netbeans-htm
> l4j-1.8/netbeans-html4j-1.8.zip.asc - these files were produced by
> https://ci-builds.apache.org/job/Netbeans/job/netbeans-html4j-release/11/
> job run.
> 
> If you want to build from the source, then unzip and use following command:
> 
> netbeans-html4j$ mvn clean install -DskipTests
> 
> you can also run the command without `-DskipTests`, but on some
> configurations, some of the tests are flaky, so your outcome may vary. I am
> often receiving test failures in `browser` module and I have to re-run the
> tests few times.
> 
> Of course, to verify the new library works, you should have an HTML/Java
> project and switch it to the new version. If you don't have such project,
> you can create one in NetBeans 13: "New Project/Java with Maven/Java
> Frontend Application" - if that application works for you, then you can
> switch to locally built HTML/Java API by changing:
> 
> --- a/pom.xml
> +++ b/pom.xml
> @@ -15,7 +15,7 @@
>  js
>  
>  
> -1.7
> +1.8
>  11
>  1.0
>  2.13
> 
> If your application continues to work, everything is OK.
> 
> In addition to the main voting artifact, we are also about to approve the
> following Maven repository:
> https://repository.apache.org/content/repositories/orgapachenetbeans-
> It has been produced by unzipping the main ZIP file and running:
> ```
> netbeans-html4j$ JAVA_HOME=/jdk-17/ mvn -Dgpg.keyname=xyz -Papache-release
> clean -DskipTests deploy ``` I'll release it to Maven central if our vote
> passes.
> 
> Please cast your votes. The vote is going to be open at least for 72h.
> -jt
> 
> 
> 
> 
> 
> -
> 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: Where to find bits.netbeans.org documents?

[Jaroslav Tulach]

The PR is accepted, but I assume you'd like me to do new maven central 
release, right?
-jt

Dne pondělí 9. května 2022 15:13:17 CEST, Eric Barboni napsal(a):
> Hi,
>  We got this issue since we build on jdk 11. We have to upgrade the code
> snippet doclet but the codesnippet is not compatible yet because of a
> classcastexception.
> 
> Issue was reported in https://issues.apache.org/jira/browse/NETBEANS-6386
> 
> Proposed PR
> https://github.com/jtulach/codesnippet4javadoc/pull/31
> 
> Once we got the new codesnippet we could fix branches release126,release130
> and release 140 and master.
> 
> Best Regards
> Eric
> -Message d'origine-
> De : antonio <>
> Envoyé : dimanche 8 mai 2022 19:42
> À : dev@netbeans.apache.org
> Objet : Re: Where to find bits.netbeans.org documents?
> 
> 1. Why are you asking?
> 
> El 8/5/22 a las 16:36, Eric Bresie escribió:
> > Is this another case that the document generation (think it uses Rake
> > at some point; is this done when the deliverables are built or is this
> > an independent build action?) is not working quite right and needs to
> > be regenerated for some of the release documentation?
> 
> -
> 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: API change

[Jaroslav Tulach]

Dne středa 11. května 2022 13:02:57 CEST, Tim Boudreau napsal(a):
> The way this has been handled in the past has been to make the method (or
> class) non-public, so it’s not visible in, say, javadoc, and then have the
> build bytecode-patch it to be public so it’s binary compatible.
> 
> At least I know we did it for some classes in openide.aww, because I
> deleted a non-public, unused class there once and found out the hard way.
> 
> Don’t know if we ever did that for methods. Jarda might.

The simplest solution is to never delete API methods. If one wants to do that 
(delete an API method or class) and has to provide good enough justification. 
The fact we managed to simplify our codebase by x-lines isn't a good enough 
justification.

E.g. keep the API methods. Thank you.
-jt


> On Tue, May 10, 2022 at 5:01 PM Łukasz Bownik 
> 
> wrote:
> > Vicrims of popularity? ;)
> > 
> > On Tue, May 10, 2022, 1:56 PM Laszlo Kishalmi 
> > 
> > wrote:
> > > Also some of the platform modules are in other exotic IDE-s like
> > > JDeveloper.
> > > 
> > > On 5/10/22 13:38, antonio wrote:
> > > > Hi,
> > > > 
> > > > You're welcome! That's a way of building trust :-).
> > > > 
> > > > Some of the committers around (not me, though) use NetBeans as a
> > > > platform for building applications, or to build plugins, so it's
> > > > always a good idea to ask in the mailing list when suggesting an API
> > > > change.
> > > > 
> > > > Kind regards,
> > > > Antonio
> > > > 
> > > > El 10/5/22 a las 22:17, Łukasz Bownik escribió:
> > > >> Thank You for explaining the process and reasoning behind it.
> > > >> It is also good to know the community's attitude towards backward
> > > >> compatibility.
> > > >> 
> > > >> I'll close the current PRs and try to spoon feed changes while
> > > >> optimising
> > > >> for "diff-readability" until we build some trust.
> > > > 
> > > > -
> > > > 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: Apache CI resource limits

[Jaroslav Tulach]

Dne neděle 15. května 2022 1:26:14 CEST, Michael Bien napsal(a):
> Hello devs,
> 
> according to [1], Apache has 180 job nodes total, shared for all Apache
> projects. If we would migrate everything from travis to github actions,
> we would use ~50 nodes for every created PR, PR update or integration.
> 
> Regarding travis [2], apache infra can't do anything about long travis
> queue times, only if there are account related issues or similar
> problems. So it appears the extremely long queue times (saw up to 20h in
> some cases) which happen every few weeks are some kind of throttling and
> no bug - but who knows.
> 
> Given this information, I believe we will have to basically keep doing
> what we are already doing: split jobs between actions and travis. We
> should also reconsider (again) if we really have to test everything in
> every PR. PHP is the problem child right now since it has a 2.5h (!) job

PHP is an important area where NetBeans IDE shines. We don't want to 
compromise that momentum. Every contributor to Apache NetBeans needs to 
understand PHP is important. However 2.5h of delay is a bit too high price for 
that.

> in a 2x matrix with a relatively high probability that one of the two
> axis randomly fails.

How many times have we encountered a failure in PHP by our non-PHP changes? 
Less than 5%? Then let's turn the check into post-PR check. Reasoning: most of 
the NetBeans development goes to Java - that doesn't influence PHP. Some 
development goes into `platform` and `ide` clusters - that may influence PHP, 
but given our strong commitment to compatibility it shouldn't. Conclusion: 
Let's run the PHP tests only when we change something in PHP cluster.

-jt

> 
> -> I don't think we can actually migrate to github actions from travis
> 
> opinions?
> 
> best regards,
> 
> michael
> 
> [1] https://infra.apache.org/github-actions-secrets.html
> 
> [2] https://issues.apache.org/jira/browse/INFRA-23257
> 
> 
> 
> -
> 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

[VOTE] NetBeans HTML/Java API 1.8

[Jaroslav Tulach]

Hi.
major improvements (introduction of `wait4java=false`) have been made in HTML/
Java API and it is time to release new version. Please help me by casting your 
votes.

This is the main voting artefact:
https://dist.apache.org/repos/dist/dev/netbeans/netbeans-html4j/netbeans-html4j-1.8/netbeans-html4j-1.8.zip
its sha512sum is 
a27af12057a588c2a232b695ef15ee573381a1356a2dcb632008ac4485d36ca7427228684b4e757ecf50231c3d5e23eb92422a9de90338d0233184b79d04626b
and I signed it as 
https://dist.apache.org/repos/dist/dev/netbeans/netbeans-html4j/netbeans-html4j-1.8/netbeans-html4j-1.8.zip.asc
 - these files were 
produced by 
https://ci-builds.apache.org/job/Netbeans/job/netbeans-html4j-release/11/ job 
run.

If you want to build from the source, then unzip and use following command:

netbeans-html4j$ mvn clean install -DskipTests

you can also run the command without `-DskipTests`, but on some configurations, 
some of the tests are flaky, so your outcome may vary. I am often receiving 
test failures in `browser` module and I have to re-run the tests few times.

Of course, to verify the new library works, you should have an HTML/Java 
project and switch it to the new version. If you don't have such project, you 
can create one in NetBeans 13: "New Project/Java with Maven/Java Frontend 
Application" - if that application works for you, then you can switch to 
locally built HTML/Java API by changing:

--- a/pom.xml
+++ b/pom.xml
@@ -15,7 +15,7 @@
 js
 
 
-1.7
+1.8
 11
 1.0
 2.13

If your application continues to work, everything is OK.

In addition to the main voting artifact, we are also about to approve the 
following Maven repository:
https://repository.apache.org/content/repositories/orgapachenetbeans-
It has been produced by unzipping the main ZIP file and running:
```
netbeans-html4j$ JAVA_HOME=/jdk-17/ mvn -Dgpg.keyname=xyz -Papache-release  
clean -DskipTests deploy
```
I'll release it to Maven central if our vote passes.

Please cast your votes. The vote is going to be open at least for 72h.
-jt





-
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: Unused method?

[Jaroslav Tulach]

The `wrapStringToArray` method is part of the module API
https://github.com/apache/netbeans/blob/master/platform/openide.util/
nbproject/org-openide-util.sig#L525
as such anyone using NetBeans Platform may use it.

The Practical Design Book tries to argue that APIs are like stars - http://
wiki.apidesign.org/wiki/Star - you cannot know "who's watching". A star cannot 
"just disappear". A method in an API cannot be "just refactored". Not even 
when it seems unused.

-jt


Dne sobota 30. dubna 2022 1:38:16 CEST, Łukasz Bownik napsal(a):
> I was supplementing and refactoring unit tests for
> /platform/openide.util/src/org/openide/util/BaseUtilities.java
>  g/openide/util/BaseUtilities.java>
> 
> 
> and I found a “*wrapStringToArray
>  8074f/platform/openide.util/src/org/openide/util/BaseUtilities.java#L306>*”
> method  which is only used in platform\openide.util.ui\src\
>  /org/openide/util/Utilities.java> org\openide\util\Utilities.
>  /org/openide/util/Utilities.java> java
>  /org/openide/util/Utilities.java> (lines 382 – 401)
> 
> 
> 
> Which defines function of exact same signature and cals the one from
> *BaseUtilities.**java.*
> 
> *Utilities.wrapStringToArray is not used anywhere.*
> 
> 
> 
> 
> 
> 
> There is another methods present in *BaseUtilities.java* called "
> *wrapString*" which in turn invokes "*wrapStringToArray*".
> platform\openide.dialogs\src\org\openide\NotifyDescriptor.java
>  8074f/platform/openide.dialogs/src/org/openide/NotifyDescriptor.java#L972>
> 
> [image: obraz.png]
> 
> 
> So I thought... maybe it makes sense to remove *Utilities.wrapStringToArray*
> and make *BaseUtilities.wrapStringToArray* private to be able to refactor
> BaseUtilities.wrapString into more efficient implementation (after writing
> characterization
> tests first).





-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: [VOTE] Release Apache NetBeans VSCode extension 13.0.301

[Jaroslav Tulach]

+1 (binding)

Signatures seems to be fine. Sources build with JDK 1.8.0 on Ubuntu.
Extension runs.
-jt


pá 15. 4. 2022 v 8:12 odesílatel Martin Balin 
napsal:

> Dear community,
> let's update the Apache NetBeans Language Server extension on VSCode
> Marketplace with significantly improved version 13.0.301
>
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/13.0.301/
>
> The primary voting artifact is the source
>
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/13.0.301/apache-netbeans-java-13.0.301-source.zip
> built from branch ‘vsnetbeans_preview_1303’
>
> SHA-512 sum is:
>
> 696eb7fc29ed18d455de0018790702218db24067b073fe29834113e421066f28021ead577f2f025286899ef6534f55929ce039fe6bfa26cc5c02976353f1ae24
> and PGP signature:
>
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/13.0.301/apache-netbeans-java-13.0.301-source.zip.asc
>
> Binary artifacts were built by:
> https://ci-builds.apache.org/job/Netbeans/job/netbeans-vscode/1030/
>
> Use following commands to build your own 13.0.301 VSIX  binary:
> $ unzip apache-netbeans-java-13.0.301-source.zip
> $ ant build
> $ cd java/java.lsp.server
> $ ant build-vscode-ext -Dvsix.version=13.0.301 -D3rdparty.modules=none
>
> In addition to the source ZIP file, we are also voting about convenience
> binary:
>
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/13.0.301/apache-netbeans-java-13.0.301.vsix
> SHA-512
> 
> sum:
>
> f6e2b0d20be21a21bbce8f7afb7ca320a603ee19b40c1c6c61a44aeea951fc67ae4eb6c4b414994e4d04d3edd6b0f64afab462da59d2e32f9697a1ac0b5b5493
> PGP signature:
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/13.0.301/apache-netbeans-java-13.0.301.vsix.asc
> The binaries has been produced by the same job run #1030 from the same
> commit
>
> This vote is going to be open at least 72 hours, vote with +1, 0, and -1
> as usual. Please mark your vote with (binding) if you're an Apache NetBeans
> PMC member.
>
> Thank you,
> Martin Balín
>
>

Re: nb-javac status update.

[Jaroslav Tulach]

> NetBeans 13 already doesn't require nb-javac if you run on JDK 17, its

> only remaining purpose is to allow users to run NetBeans on older JDKs.
>

Given the javac API (including trees API & other internals as used by
NetBeans) isn't developed in a compatible way, it is not guaranteed at all
NetBeans 13 can use javac from newer JDK than 17. I suggest to rephrase as:

NetBeans 13 already doesn't require nb-javac if you run on JDK 17, its
purpose is to allow users to run NetBeans on other JDKs than 17.
-jt

Re: NetBeans behavior for missing project specific java platform

[Jaroslav Tulach]

FYI: https://github.com/apache/netbeans/pull/3715 
-jt

Dne neděle 3. dubna 2022 9:11:19 CEST, Patrik Karlström napsal(a):
> I ran into a problem this morning.
> Started NetBeans 13 (as a snap on debian) and as soon as I tried to save a
> changed java file NetBeans froze completely. Killed it and tried again,
> same result each time.
> 
> Everything was working fine the last time I did this before today.
> 
> After a dog walk in the woods it hit me it could be related to my jdk
> cleanup with sdkman.
> It turned out that my current maven project has a project specific java
> platform, but now non existing.
> 
> Can NetBeans handle this with more grace than just a freeze?
> 
> My messages.log ends with
> 
> Even though the source level of
> /home/patrik/git/java/jotasync/src/main/java:/home/patrik/git/java/jotasync/
> src/main/resources is set to: 17, java.lang.AssertionError cannot be found
> on the
> bootclasspath:
> Changing source level to 1.3
> WARNING [org.netbeans.TopSecurityManager]: use of system property
> netbeans.user has been obsoleted in favor of InstalledFileLocator/Places at
> org.netbeans.modules.java.source.parsing.JavacParser.createDumpFile(JavacPar
> ser.java:1284) SEVERE [org.openide.util.Exceptions]
> An error occurred during parsing of
> '/home/patrik/git/java/jotasync/src/main/java/se/trixon/jota/client/ui/App.j
> ava'. Please report a bug against java/source and attach dump file
> '/home/patrik/snap/netbeans/58/var/log/App.dump'.
> An error occurred during parsing of
> '/home/patrik/git/java/jotasync/src/main/java/se/trixon/jota/client/ui/App.j
> ava'. Please report a bug against java/source and attach dump file
> '/home/patrik/snap/netbeans/58/var/log/App.dump'.
> Caused: com.sun.tools.javac.code.Symbol$CompletionFailure: class file for
> java.lang.Boolean not found
> Caused: java.lang.IllegalStateException:
> com.sun.tools.javac.code.Symbol$CompletionFailure: class file for
> java.lang.Error not found
> at com.sun.tools.javac.api.JavacTaskImpl.analyze(JavacTaskImpl.java:383)
> at
> org.netbeans.modules.java.source.parsing.JavacParser.moveToPhase(JavacParser
> .java:769) at
> org.netbeans.modules.java.source.parsing.JavacParser.getResult(JavacParser.j
> ava:539) at
> org.netbeans.modules.java.source.parsing.JavacParser.getResult(JavacParser.j
> ava:140) at
> org.netbeans.modules.parsing.impl.TaskProcessor.callGetResult(TaskProcessor.
> java:608) at
> org.netbeans.modules.parsing.impl.SourceCache.getResult(SourceCache.java:239
> ) at
> org.netbeans.modules.parsing.impl.TaskProcessor$RequestPerformer.run(TaskPro
> cessor.java:775) at
> org.openide.util.lookup.Lookups.executeWith(Lookups.java:279)
> at
> org.netbeans.modules.parsing.impl.TaskProcessor$RequestPerformer.execute(Tas
> kProcessor.java:702) [catch] at
> org.netbeans.modules.parsing.impl.TaskProcessor$CompilationJob.run(TaskProce
> ssor.java:663) at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java
> :539) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418)
> at
> org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
> at org.openide.util.lookup.Lookups.executeWith(Lookups.java:278)
> at
> org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)
> ALL [null]: An error occurred during parsing of
> '/home/patrik/git/java/jotasync/src/main/java/se/trixon/jota/client/ui/App.j
> ava'. Please report a bug against java/source and attach dump file
> '/home/patrik/snap/netbeans/58/var/log/App.dump'.
> SEVERE [null]: Last record repeated again.
> INFO [org.netbeans.modules.bugtracking.BugtrackingManager]: Loading stored
> repositories took 51 millis.
> INFO [org.netbeans.ui.metrics.bugtracking]: USG_ISSUE_TRACKING_REPOSITORY





-
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-javac status update.

[Jaroslav Tulach]

> Dear Arvind,
> 
> Thank you for your and Oracle work to integrate nb-javac features into
> javac!

Yes, it is great to see all the features essential for editing Java in an IDE 
are already part of OpenJDK 17 javac compiler!

> the migration effort to the JDK javac has been completed!

If anyone observes a bug while editing Java in the Apache NetBeans IDE, go to 
https://github.com/openjdk/jdk and fix it  there - that's where the javac 
(formerly nb-javac) code lives!

> Also you or @Jaroslav can mention, that nb-javac is still alive as a
> generated library from the Java 17+ Javac which is compatible with Java
> 8 runtime.

The build scripts are available at https://github.com/JaroslavTulach/nb-javac/ 
- however the Java code comes from https://github.com/openjdk/jdk - the build 
script checks the official OpenJDK repository out and just packages the sources 
into binaries suitable for NetBeans purposes.

-jt

> On 3/28/22 10:56, Arvind Aprameya wrote:
> > Hi All,
> > 
> > Since the contribution of the NetBeans IDE to Apache, Oracle had been the
> > primary maintainer of the nb-javac patched code and distributed the
> > nb-javac plugin and source to be used in the NetBeans IDE.  We appreciate
> > the NetBeans Apache community members who contributed to the nb-javac
> > plugin over the years.  The most recent plugin code was published in Oct
> > 2021 [1].  While we ensured the plugin availability for every new JDK
> > release, we also worked towards enabling NetBeans to directly use the JDK
> > javac compiler.  We are happy to announce that the migration effort to
> > the JDK javac has been completed!  NetBeans version 13 release can use
> > the javac implementation in OpenJDK 17 for editing code on any language
> > level supported by the OpenJDK 17 javac compiler.  As this migration is
> > completed, we will stop distributing the code and the nb-javac plugin
> > going forward.  Once again, we would like to thank the NetBeans Apache
> > community for their collaboration.
> > 
> > [1] https://github.com/oracle/nb-javac
> > 
> > regards,
> > Arvind





-
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: html view of test result

[Jaroslav Tulach]

Dne pátek 18. března 2022 20:30:29 CEST, antonio napsal(a):
> This is a great job. Thanks!!

+1
-jt

> 
> El 18/3/22 a las 18:48, Eric Barboni escribió:
> > Hi folks,
> > 
> > I was a bit long on this one but netbeans-matrix jobs propagate unit
> > results to our bits.netbeans.org website.
> > 
> > Currently the axis are jdk (jdk_1.8_latest, jdk_11_latest, jdk_17_latest)
> > and clusters (ide,platform). No index so the link are here with the
> > pattern
> > https://bits.netbeans.org/matrix/unit///html/
> > 
> > For platform
> > https://bits.netbeans.org/matrix/unit/jdk_1.8_latest/platform/html/
> > https://bits.netbeans.org/matrix/unit/jdk_11_latest/platform/html/
> > https://bits.netbeans.org/matrix/unit/jdk_17_latest/platform/html/
> > 
> > For ide
> > https://bits.netbeans.org/matrix/unit/jdk_1.8_latest/ide/html/
> > https://bits.netbeans.org/matrix/unit/jdk_11_latest/ide/html/
> > https://bits.netbeans.org/matrix/unit/jdk_17_latest/ide/html/
> > 
> > Build is run by hand because it's a bit heavy.
> > https://ci-builds.apache.org/job/Netbeans/job/netbeans-matrix/
> > 
> > The current pipeline configuration is stored there:
> > https://github.com/apache/netbeans-jenkins-lib/blob/master/jobs/Jenkinsmat
> > ri xfile.groovy
> > 
> > Happy exploring
> > Best Regards
> > Eric
> > 
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> > For additional commands, e-mail: dev-h...@netbeans.apache.org
> > 
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
> 
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists





-
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-javac on JDK 17

[Jaroslav Tulach]

Dne pondělí 14. března 2022 6:19:25 CET, Tim Boudreau napsal(a):
> Is there an update for using nb-javac with JDK 17?

https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac
-jt


> 
> I've been finding, for some runs of NetBeans, parsing and semantic
> highlighting do not work, and you get some log messages saying that a null
> parser was returned for whatever file is being parsed.
> 
> I had been using version 15 (or is it JDK 15 specific - it was the suffix
> to the JAR name), patched to fix the maven scanning bug with a pull request
> I sent last year.
> 
> Building the trunk and copying it over the JARs in modules/ext in my
> userdir solved that problem, but - is there an actual release that contains
> this code?  Known problem?
> 
> -Tim





-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: master is now buildable on JDK 17

[Jaroslav Tulach]

Great to see NetBeans builds with the latest long term support JDK! Thanks
for polishing the build.

Shall we require JDK 17 as the minimum JDK to build NetBeans?
-jt

PS: Of course, newer JDK APIs can only be used in [alternative modular
implementations](http://wiki.apidesign.org/wiki/AlternativeImplementation)

Nice!  I just did a build on macOS with JDK 17.0.2:
>
> ant -Dcluster.config=full
> …
> BUILD SUCCESSFUL
> Total time: 9 minutes 54 seconds
>
> > On Mar 12, 2022, at 8:13 PM, Michael Bien  wrote:
> >
> > with all clusters, as seen here:
> >
> > https://github.com/apache/netbeans/runs/5524901974
> >
> > best regards,
> >
> > michael
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: [DISCUSS] Travis failures and nb-javac on Java 8

[Jaroslav Tulach]

ne 6. 3. 2022 v 17:02 odesílatel Michael Bien  napsal:

> On 06.03.22 16:06, Jaroslav Tulach wrote:
> >> But as you pointed out some modules which are used by the language
> >> server have to be kept compatible with 8 unfortunately, which causes a
> >> lot of ongoing issues but it is what it is.
> > Can I get pointer to the list of "lot of ongoing issues", please? Thank
> you.
>
> I don't know of any readily available list, but there is a lot of energy
> spent to maintain compatibility with JDK 8.


Please assemble that list. I will be more easier to get convinced once I
see the real issues.



> But to pick a concrete (while random) example: lucene 9.x only supports
> JDK11+, the maven indexer modules are stuck with 5.x, updating it to 8.x
> might require manually patching a certain bugfix form 9.x to 8.x since
> there are no new releases planned for 8.x.
>

The last release of 8 is from December:
https://lucene.apache.org/core/corenews.html#apache-lucenetm-8111-available
- I am sure critical bugfixes will be backported.


> That is what i mean by ongoing issues. In other words: extra work caused
> by technical dept.
>

Technical dept!? Technical dept is that NetBeans tests are flaky and
failing. Not addressing the unreliability of the tests is the problem. That
has nothing to do with discussion about JDK version!
-jt

Re: [DISCUSS] Travis failures and nb-javac on Java 8

[Jaroslav Tulach]

I see "The moment" vs. "At the moment". Yes, then it is not "F.U.D", but a
serious evaluation. Sorry for the misreading - I wasn't expecting switch to
reasonable arguments after two paragraphs of offense.
-jt


út 8. 3. 2022 v 12:40 odesílatel Neil C Smith 
napsal:

> On Tue, 8 Mar 2022 at 11:14, Jaroslav Tulach 
> wrote:
> >
> > Spreading F.U.D., Matthias?
> >
> > The moment you can't compile for JDK 8 anymore with the currently
> > > available JDK
> >
> > jdk-17/bin/javac --help | grep release
>
> I think you mis-read his post!
>
> I broadly agree with him, although I think that particular point is
> probably still a little way away.
>
> 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: [DISCUSS] Travis failures and nb-javac on Java 8

[Jaroslav Tulach]

Spreading F.U.D., Matthias?

The moment you can't compile for JDK 8 anymore with the currently
> available JDK


jdk-17/bin/javac --help | grep release
   Enable preview language features. To be used in conjunction with
either -source or --release.
 --release 
   Compile for the specified Java SE release. Supported releases: 7, 8,
9, 10, 11, 12, 13, 14, 15, 16, 17
 --source , -source 
   Provide source compatibility with the specified Java SE release.
Supported releases: 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17
 --target , -target 
   Generate class files suitable for the specified Java SE release.
Supported releases: 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17
-jt

Re: [DISCUSS] Travis failures and nb-javac on Java 8

[Jaroslav Tulach]

Dne neděle 6. března 2022 13:46:23 CET, Michael Bien napsal(a):
> On 06.03.22 05:07, Jaroslav Tulach wrote:
> > Dne sobota 5. března 2022 17:54:46 CET, antonio napsal(a):
> >> a) do we need these now that JDK >= 11 is required to run NetBeans?
> >> b) if not, can we get rid of them?
> > 
> > No, we cannot get rid of them. While we are compiling on JDK11, the
> > requirement still is to run and test on JDK8. That can only change with
> > voting.
> 
> Hi Jaroslav,
> 
> NB 12.6 and 13 itself only support JDK 11 and 17, if some of it still
> runs on 8 its a coincidence. Nobody should run the IDE on 8.

I do. I am running my NetBeans on JDK8 based GraalVM. And it is not a 
coincidence - it is an important use-case for my business unit.

> But as you pointed out some modules which are used by the language
> server have to be kept compatible with 8 unfortunately, which causes a
> lot of ongoing issues but it is what it is.

Can I get pointer to the list of "lot of ongoing issues", please? Thank you.

> i can't even vote on it since i am a mere contributor, but am sure
> someone could setup a vote for the second part if there is demand, but
> the first decision was already made (here on the list) and the releases
> are public.

Yes, the decision is: the tests must run on JDK8. If you disagree with my 
statement, present an evidence: show me where a decision to drop JDK8 for 
(automatic) testing has been made!

> Apache released binaries require JDK 11/17

Not technically - the binaries run on JDK8 fine. Apache NetBeans project just 
doesn't provide support for those who run complementary binaries on JDK8. End 
users certainly shall use JDK11+ - integrators building on top of NetBeans 
Platform can however use JDK8.
-jt




-
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

Disable failing CI tests wasa: [DISCUSS] Travis failures and nb-javac on Java 8

[Jaroslav Tulach]

Dne sobota 5. března 2022 19:21:53 CET, Michael Bien napsal(a):
> > So it seems our Travis builds fail randomly on (at least) the
> > following tasks:
> 
> yes those are known to fail, esp job 13. I had to brute force this one 5
> times yesterday until it passed - i almost reverted a PR since I thought
> i broke master. (PR was green but master kept failing after merge)

Annotate the randomly failing test with `@RandomlyFails` annotation when you 
encounter. Then it is no longer going to block CI.

It is responsibility of the module owners to fix their tests to be stable. If 
they aren't able to do so. They have to accept such tests being disabled.

-jt




-
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: Setting Up a File for Use Unit Tests

[Jaroslav Tulach]

Dne sobota 5. března 2022 17:22:49 CET, Eric Bresie napsal(a):
> While writing unit tests for my python development (modeled on existing
> unit code in the nbpython codebase) to test "execution of a script", I'm
> having problems injecting the "test.py" code and was hoping someone could
> provide some guidance on standardize unit test setup in Netbeans IDE/Module
> development.
> 
> The previous tests looks for some file in a "target/data" folder which in
> my new codebase is not created in any way.

Using [NbTestCase.getDataDir()](https://github.com/apache/netbeans/blob/
master/harness/nbjunit/src/org/netbeans/junit/NbTestCase.java#L1223).

> So what is the proper way to deal with unit test resources to include
> (1) generate a "test file" in a standardized way (i.e. store in above
> mentioned "target/data" folder)
> (2) reference another file (i.e. a template file associated within the
> code, reference a "test resource", etc.)?

I tend to use `Class.getResource("my.py")` and copy it into a temporary 
directory.

-jt

> I have a "template.py" currently used in "new file creation" which maybe
> could be used and have added a "test resource" hello.py code but not sure
> if there is a standardized way of using either of these in Netbeans unit
> testing.
> 
> 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: [DISCUSS] Travis failures and nb-javac on Java 8

[Jaroslav Tulach]

Dne sobota 5. března 2022 17:54:46 CET, antonio napsal(a):
> a) do we need these now that JDK >= 11 is required to run NetBeans?
> b) if not, can we get rid of them?

No, we cannot get rid of them. While we are compiling on JDK11, the 
requirement still is to run and test on JDK8. That can only change with 
voting.

See discussion: https://lists.apache.org/thread/
0kph6rg6djb2y77l0v9n9cn67dbkwr8h

> The objectives being:
> - Making Travis builds consistent and reliable.

That's is desirable goal, but it has nothing to do with JDK8. The same tests 
would remain shaky on any JDK. In any case, we shall update our jobs. The IDE 
should be built with JDK11 and test with other JDKs:

Sample code doing that: 
https://github.com/apache/netbeans/pull/3418/files#diff-f2b504a5dd489bbf1a9e22cf5a3ff2f3ab469fabe9dd52ff6945482f9f356a34R57

> - Reducing the amount of trees we burn to run Travis builds.

That would better be done by using "pipelines" - e.g. build NetBeans IDE first 
on JDK11 and then test the binary on other systems.

See discussion: https://lists.apache.org/thread/
qdltpyjrznj5bqdrq4symcl02npg63z3


Let's start by updating our jobs to build with JDK11 and continue to test with 
the same JDK as they do now, please!
-jt




-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

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

[Jaroslav Tulach]

> I've held off closing the release vote for now, but if we don't know
> for sure by the end of the week, should we then move to release
> everything else?  This will leave macOS users having to use the zip
> release, at least in the short term.
>
> Thoughts / objections?
>

Expressing my 2 Kč opinion: I am waiting for NetBeans 13 to be released.
Please release in a timely manner. I don't care about Mac OS X installer.
-jt

Re: Does NetBeans support multi-jar releases?

[Jaroslav Tulach]

Dne středa 2. března 2022 13:59:44 CET, Christian Oyarzun napsal(a):
> Hi Ernie,
> 
> Maybe someone with more knowledge of this can provide a better answer.
> 
> NetBeans has some support for multi-release jars.
> https://github.com/apache/netbeans/pulls?q=is%3Apr+is%3Aclosed+%22multi-rele
> ase%22+jar+
> 
> I was missing the key word 'not' in my last email response. The classloader
> does 'not' support multi-release jar files like log4j.
> https://issues.apache.org/jira/browse/NETBEANS-3679
> 
> I think we need to modify
> https://github.com/apache/netbeans/blob/master/platform/o.n.bootstrap/src/or
> g/netbeans/JarClassLoader.java to support multi-release jars.
> Something akin to what Spring did
> https://github.com/spring-projects/spring-boot/commit/56eebc9385e6c458a18e05
> 115ceaf0df73bfbc02


Yup. That sounds like correct reasoning with respect to `JarClassLoader`.

Just one question: Is `JarClassLoader` involved when it comes to loading form 
editor JavaBeans at all?
-jt





-
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: VSCode plugin, and BOUNTIES!

[Jaroslav Tulach]

Wow,
putting you money where your mouth is! Amazing and not too frequent attitude 
in the open source community.  That is very encouraging.

> I just wanted to say that I recently switched from VS Code’s semi-official
> java plugin (which is practically unusable for large projects) to the
> Netbeans VSCode plugin recently, and the NetBeans approach is already
> better in most respects—thank you!

Great to hear that.

> I’ve used used Netbeans since it’s inception—that’s over 20 years—and I
> truly believe the language server/plugin approach is the future for
> Netbeans. Let other people worry about the non-specific editor/IDE features
> like remote development via an SSH tunnel (one of the the reasons I had to
> switch from NetBeans), and focus on what you do best: development-specific
> features. This is just my opinion, but it’s the opinion of someone who has
> been around for a while and has seen the direction things are going.

Right, I am using VSCode+Apache NetBeans Language Server extension to develop 
Java code for OracleDB - via an SSH connection across the Atlantic ocean. It 
works great and the synergy of Microsoft and us really pays off by making such 
high quality remote development possible.

> I’m so sure of this, I’m willing to put my money where my mouth is (well, a
> modest amount of money). I think the most glaring feature missing right now
> is the ability format java files, and configure how they’re formatted. I
> know the plumbing/code is probably already in there, because it’s used to
> order imports. I’m offering a $250 USD bounty to anyone who gets a PR
> accepted that gets the rest of this done. I’d expect that it would offer
> similar options to what is currently in NetBeans proper.

The formatting has been on OracleLabs tooling team roadmap for a few releases, 
but it always slipped off. The $250 personal bonus for the developer who 
integrates it shall be enough to put it on the schedule again.

My personal take on it is however slightly negative - as I am not satisfied 
with the formatting options NetBeans offers currently. My thinking is:

- in order for formatting to be useful (e.g. not a toy), it must be enforced
- enforcing happens in the CI
- commits violating the formatting shall be rejected
- IDE should help to identify code that would be rejected

Such a system is out of the scope of the current NetBeans formatting. However 
it is the only one that fits 21st century. As such I always argued that it 
makes no sense to invest in 1:1 recreation of existing toy-like NetBeans 
formatting in VSCode.

But $250 is good enough bonus for something that had always had to happen, 
eventually. It shouldn't be that hard - as you say - the functionality is 
already there and enough to hook it with VSCode.

-jt

PS: ...

> Don’t have that much NetBeans development experience but still want to get
> in on the action? Here’s an easy one: $75 to create a VS Code plugin that
> emulates the NetBeans previous/next matching word functionality. That’s it!
> I miss that feature a LOT.


Ctrl-L? VSCode offers word based code completion by itself and I've kinda got 
used to it.

Alt-Up or Alt-Down? Yup, that'd be great. I certainly miss it.

> P.S. - is there a bounty board still active somewhere where I can post this?

Many years ago I tried to set nbbounty.org up, but we never got it running.




-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: [VOTE] Release Apache NetBeans 13.0 VSCode extension

[Jaroslav Tulach]

+1 (binding)

Checksum OK - please include it in the voting email next time
Signed OK - congrats, Martine!
Kinda works - able to open some Gradle projects and play with them as expected

> Dear community,
> 
> Vote for NetBeans 13.0 extension for VSCode (VSIX).
> Primary voting artefact is :
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/13.0/apa
> che-netbeans-java-13.0.0.vsix
> 
> SHA512 sum:
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/13.0/apa
> che-netbeans-java-13.0.0.vsix.sha512
> 
> PGP signature:
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/13.0/apa
> che-netbeans-java-13.0.0.vsix.asc
> 
> Built by Jenkins job
> https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/netbeans/job/
> release130/20/ from the same sources as main voting artefact or 13.0
> 
> This vote is going to be open at least 72 hours, vote with +1, 0, and -1 as
> usual. Please mark your vote with (binding) if you're an Apache NetBeans
> PMC member.
> 
> This vote is dependent on main NetBeans 13.0 voting result.
> 
> Thank you,
> Martin





-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: [VOTE] Release Apache NetBeans 13

[Jaroslav Tulach]

+1 (binding)

> 
> 
> We are primarily voting on :
> 
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans/13/netbeans-13-sour
> ce.zip
> 
> SHA512 :
> 40776cf1962989c50c94f4a16784c2519d15100f5949e6d447ffb78b80f93a10707703824ad
> 9f50232f380108caeff76fa4660679840ca4ee6899e8a5fc3e821
> 
> KEYS file : https://downloads.apache.org/netbeans/KEYS
> 
> 

Checksum & GPG is OK. The source builds with JDK-11 and then runs on JDK-8.

> Associated with the primary source item we have, generated with the
> pipeline mentioned above :
> 
> -- at https://dist.apache.org/repos/dist/dev/netbeans/netbeans/13/

Checksum & GPG of the binary seems OK + the IDE starts on JDK 8 and I can work 
with Maven and Gradle projects.

> 
> 
> Maven Artefacts
> 
> The Maven artefacts for Apache NetBeans 13 are ready on staging
> associated to this vote.
> 
> https://repository.apache.org/content/repositories/orgapachenetbeans-1102/
> 
> The version is : RELEASE130
> 
> 

I am able to build https://github.com/apache/netbeans-html4j/ with the new 
Maven JARs:

netbeans-html4j$ git diff pom.xml
diff --git a/pom.xml b/pom.xml
index 2b9b0ae3..2cc56aff 100644
--- a/pom.xml
+++ b/pom.xml
@@ -33,7 +33,7 @@
   
   
   UTF-8
-  RELEASE125
+  RELEASE130
   21.3.0
   2.3.8
   COPYING


> 
> Voting Requirements
> 
> Before voting +1 you are required to download the signed source code
> package, compile it as provided, and test the resulting executable on
> your own platform, along with also verifying that the package meets
> the requirements of the ASF policy on releases -
> http://www.apache.org/legal/release-policy.html#management
> 
> In particular, you should (at least) follow these steps.
> 
> 1. Download the artefact to be voted on and unzip it.
> 2. Check that the artefact does not contain any jar files (there are
> branding folders with the name *.jar).
> 3. Verify the cryptographic signatures, the NOTICE and LICENSE file
> 4. Build it using the README provided by the artefact.
> 5. Look in nbbuild/netbeans for the NetBeans installation created by
> the build process and try running it.
> 
> In addition to checking the sources, you should check the associated
> convenience binary zips, nbms and maven staging at the artefact links
> above. As well as checking any artefact functions correctly, you
> should check that it has been correctly signed by a PMC member, and
> that the source being voted on is sufficient to build the relevant
> binary.
> 
> Separate votes will be held on other convenience binaries, including
> installers. Those will be dependent on this vote passing.
> 
> This vote is going to be open at least 72 hours, vote with +1, 0, and
> -1 as usual. (Please justify -1)
> 
> Please mark your vote with (binding) only if you're an Apache NetBeans
> PMC member to help with voting admin.
> 
> Only respond if you are going to vote, i.e., this is NOT a discussion
> thread.
> 
> Apache NetBeans 13 will be released if and when this vote passes.
> 
> Thank you to all contributors for all your hard work!
> 
> Best wishes,
> 
> Neil, Eric and Geertjan
> Apache NetBeans release team
> 
> -
> 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: No main manifest attribute in jar in Maven project

[Jaroslav Tulach]

Dne čtvrtek 17. února 2022 1:45:20 CET, Vladimir Machat napsal(a):
> Thanks, I know how to do it, I was just wondering why it's not done by
> Netbeans the same it is done for Ant project...

Improvements and contributions to
https://github.com/apache/netbeans/pull/3262
welcomed!
-jt


> 
> On 16/02/2022 21:31, Tim de Vries wrote:
> > I have a tool which packages to executable jar with optional manifest
> > attributes. I was hoping to charge $1/user/month. I don’t know if that’s
> > allowed here.
> > 
> > Sent from my iPhone
> > 
> >> On Feb 16, 2022, at 11:55 AM, antonio  wrote:
> >> 
> >> Hi,
> >> 
> >> Adding the main class in MANIFEST.MF is not good enough to run a Maven
> >> project with "java -jar". You also want to create a "fat jar" with all
> >> the dependencies in it. See [1] for guidance.>> 
> >>> Is there a reason why Netbeans doesn't do it?
> >> 
> >> Here're some possible answers (of my own, doesn't mean NetBeans endorses
> >> them):
> >> 
> >> a) I don't like my IDE to mess around with my pom.xml files but for very
> >> specific things (adding dependencies, for instance). b) This is
> >> something users are expected to do.
> >> c) This is project-specific. Maven based Spring-Boot projects, for
> >> instance, have a main class of their own. NetBeans Platform based
> >> projects do also have a main class of their own. d) Nobody has created a
> >> PR for this feature.
> >> 
> >> Hope this helps,
> >> Antonio
> >> 
> >> [1]
> >> https://www.baeldung.com/executable-jar-with-maven
> >> 
> >>> El 16/2/22 a las 11:43, Vladimir Machat escribió:
> >>> Hi all,
> >>> I was just wondering, is Netbeans supposed to fill out the main
> >>> attribute in MANIFEST.MF that goes to the jar file, when building Maven
> >>> project? At the moment it doesn't do it, which means that the resulting
> >>> jar can't be executed just by $ java -jar App.jar
> >>> I would expect Netbeans to set the main attribute when setting the main
> >>> class either in the Project properties or when it asks you the very
> >>> fist time you run the application in the IDE. Is there a reason why
> >>> Netbeans doesn't do it?
> >>> Thanks
> >>> Vlad
> >> 
> >> -
> >> 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: [VOTE] Release of Apache NetBeans utilities nbm-maven-plugin version 4.7

[Jaroslav Tulach]

+1 (binding)

Checksum and signature OK. It builds with JDK8 on Kubuntu.
-jt


Dne čtvrtek 10. února 2022 18:25:02 CET, Eric Barboni napsal(a):
> Dear members of Apache NetBeans community.
> 
> 
> 
> I want to call a vote on releasing Apache NetBeans utilities
> nbm-maven-plugin version 4.7.
> 
> 
> 
> nbm-maven-plugin 4.7 is a maven plugin that allow to build/run Apache
> NetBeans Platform using maven artefacts.
> 
> Changes from 4.6:
> 
> NETBEANSINFRA-262  Fixed missing Class-Path URL decoding
> 
> version of asm 9.2 to be able to use jdk 17
> 
> 
> 
> fixes on the web page
> 
> 
> 
> The voted artefacts sources are located here:
> 
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-maven-utilities/nbm
> -maven-plugin/nbm-maven-plugin-4.7/
> 
> 
> 
> In addition to that, Maven artifacts built from
> https://github.com/apache/netbeans-mavenutils-nbm-maven-plugin
> 
> with the commit id 9c1fe033eae4361d6b31504d926f1a4e5151a890(tag
> nbm-maven-plugin-4.7) are staged in the following repository:
> 
> 
> 
> https://repository.apache.org/content/repositories/orgapachenetbeans-1096/
> 
> 
> 
> sha512 is:
> 
> 7dbfec7a48a8ec3660dde21a4317bc40cadd53a476b60d5c4eba06c3afac240af164eca0e069
> b2a4867d832dd7ee37c4dc9049dcde41b9b669d517165792815c
> 
> 
> 
> Key file is here:
> 
> https://www.apache.org/dist/netbeans/KEYS
> 
> 
> 
> The vote is open for at least 72h.
> 
> Best Regards
> 
> 
> 
> Eric Barboni (skygo)





-
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: Building master with JDK11?

[Jaroslav Tulach]

Dne pondělí 14. února 2022 22:13:36 CET, Michael Bien napsal(a):
> thats what ant clean should probably invoke :) (I am kidding)

It used to! `ant clean` used to do some `hg clean` magic while NetBeans was 
still using Mercurial. I see no problem changing it to use another git magic - 
please purge only files that are `.gitignored` otherwise developers may loose 
some work.

-jt


> On 14.02.22 22:12, Laszlo Kishalmi wrote:
> > git clean -xfd
> > 
> > On 2/14/22 13:07, antonio wrote:
> >> Yep, building in a clean clone does indeed work.
> >> 
> >> It seems we have a dirty bug in a clean target!
> >> 
> >> Thanks!
> >> Antonio
> >> 
> >> El 14/2/22 a las 21:50, Michael Bien escribió:
> >>> just to exclude that this is a similar issue, could you try building
> >>> a fresh checkout in some temp folder like i just did?
> >> 
> >> -
> >> 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





-
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-javac and timing

[Jaroslav Tulach]

> the schedule lets NB systematically lack one update release behind.

I don't think that is a real problem.  Unless there is a specific NetBeans bug 
that requires update of JDK's javac, we don't have to be "at the tip". Most of 
the bugfixes backported to 17.0.x version aren't going to affect user 
experience 
at all - 99.9% percent of Java developers are unlikely to notice a difference.

We have to make sure NetBeans 14 stay close to the most recent major version 
(which we shall be able to as https://github.com/JaroslavTulach/nb-javac/pull/
2 has already been integrated). 

-jt

Dne neděle 23. ledna 2022 11:33:49 CET, Michael Bien napsal(a):
> On 23.01.22 09:22, Jaroslav Tulach wrote:
> > Dne úterý 18. ledna 2022 21:21:54 CET, Michael Bien napsal(a):
> >> Hello Everyone,
> >> 
> >> since 17.0.2 was just released
> > 
> > Do you want to generate a new version of nb-javac binary? Create a PR for
> > https://github.com/JaroslavTulach/nb-javac/
> > 
> > -jt
> 
> NB is basically in rc 2 by now, I am pretty sure its too late for that
> (which was the point of the mail btw).
> 
> (generating nb-javac from jdk-17.0.2+8 seems to be working fine though,
> no changes required from master beside the property file as far as I can
> tell - but i lack experience there and i ran no other tests beside the
> test task)
> 
> the schedule lets NB systematically lack one update release behind.
> 
> javac 18.0.1 would be released during NB 14 rc phase which means that NB
> will probably ship with javac 18+35.
> 
> -mbien





-
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: Code Templates & lambdas

[Jaroslav Tulach]

Dne neděle 30. ledna 2022 12:32:22 CET, Michael Bien napsal(a):
> On 30.01.22 04:34, Jaroslav Tulach wrote:
> >>>> It's funny how that change has made it both far easier to change and
> >>>> yet somehow far more confusing for people.
> > 
> > ;-)
> > 
> >> ... Check
> >> https://github.com/apache/netbeans/pull/2960 and maybe suggest an
> >> improved text in a follow up PR?
> > 
> > Right.
> > 
> > I happily review any PR related to the #2960 improvement.
> > -jt
> 
> is it possible to hide some templates from the user?
> 
> I tried to implement auto completion for lambda expressions here:

Hello Michalel,
this part was written by Dušan Bálek. CCing.
-jt


> 
> https://github.com/apache/netbeans/pull/3458
> 
> The problem is that the inserted code is a template (which doesn't do
> anything interesting anyway) and it doesn't really make sense to let the
> user edit lambda templates (esp not for expressions). The completion
> logic has to mark the inserted code with ${..} so that the user can jump
> with tab between selected sections after completion. If someone would
> edit the template this all would break quickly.
> 
> -mbien





-
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: That Darn License Header

[Jaroslav Tulach]

> > > It's funny how that change has made it both far easier to change and
> > > yet somehow far more confusing for people.

;-)


> ... Check
> https://github.com/apache/netbeans/pull/2960 and maybe suggest an
> improved text in a follow up PR?

Right.

I happily review any PR related to the #2960 improvement.
-jt




-
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-javac and timing

[Jaroslav Tulach]

Dne úterý 18. ledna 2022 21:21:54 CET, Michael Bien napsal(a):
> Hello Everyone,
> 
> since 17.0.2 was just released 

Do you want to generate a new version of nb-javac binary? Create a PR for 
https://github.com/JaroslavTulach/nb-javac/

-jt




-
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: Frontend application (Dukescript) wizard broken in NB 13-rc1

[Jaroslav Tulach]

Dne pátek 21. ledna 2022 13:12:40 CET, Neil C Smith napsal(a):
> Hi,
> 
> On Fri, 21 Jan 2022 at 07:54, Geertjan Wielenga
> 
>  wrote:
> > Wow, excellent, no dialogs or popups or nb-javac messages or messages
> > about
> > JavaFX.
> 
> This gave me a thought.  You should still see the JavaFX message if
> you try to create a Java Frontend Application project.  Now nb-javac
> is included, the message appears, but the wizard seems not to work at
> all.
> 
> If you manually install the JavaFX modules, then restart, it does.
> 
> Anyone interested in that wizard working might want to look at this! :-)

As a maintainer of HTML4J I am indeed interested in this. What's the problem?

I've just built NetBeans from most recent `delivery` branch (`83fe4039dc`) and 
used the Maven/Java Frontend Application wizard on JDK-11. I could see the UI 
and the UI was "interactive".

-jt




-
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: Excluding a module from build depending on JDK?

[Jaroslav Tulach]

út 11. 1. 2022 v 13:54 odesílatel Neil C Smith 
napsal:

> Hi,
>
> Anyone know if there's a non-hacky way to exclude a module from being
> included at all if building the IDE on JDK 8?


There was an agreement to require JDK-11 to build NetBeans code.


> I was under the
> impression there might be in the conversations about support of
> --release 11, but I now think I might have misinterpreted something
> that was said.
>
> Ideally all our tests would be building on JDK 11 now,


Our tests shall continue to run on JDK-8. There was no consensus to move
away from JDK-8 when running tests, as far as I can tell.

The ideal setup is shown at
https://github.com/apache/netbeans/blob/master/.github/workflows/ensure-jdk8.yml

E.g. build with JDK-11, but test on JDK-8. That's what needs to happen to
all CI jobs, before one can use `--release 11`.
-jt

Re: JavaFX classpath warning when building NB RCP with Maven

[Jaroslav Tulach]

FYI: https://github.com/apache/netbeans/commit/1b96b56 & co.

It gets interpreted by the NetBeans runtime system.
-jt


čt 13. 1. 2022 v 21:30 odesílatel Jean-Marc Borer 
napsal:

>
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
>
> But still, it is a very special case here since I have never seen URL such
> as "%24%7Bjava.home%7D%2F/lib/ext/jfxrt.jar". ${xxx} is a dynamic value
> that shall be replaced at runtime. I really wonder if the manifest gets
> properly interpreted with such a construction.
>
> On Thu, Jan 13, 2022 at 8:25 PM Jean-Marc Borer  wrote:
>
> > True. Then the issue lies in the maven nbm plugin that doesn't understand
> > the URL escaping.
> >
> > I tested by manually modifying the manifest to restore the old values.
> The
> > warning message is gone.
> >
> > On Thu, Jan 13, 2022 at 7:04 PM Matthias Bläsing <
> > mblaes...@doppel-helix.eu> wrote:
> >
> >> Hi,
> >>
> >> Am Donnerstag, dem 13.01.2022 um 17:54 + schrieb Jean-Marc Borer:
> >> > When building my NB RCP application with Maven, I get:
> >> >
> >> > Could not resolve Class-Path item in
> >> > org.netbeans.api:org-netbeans-libs-javafx:nbm-file:RELEASE124, path
> >> > is:%24%7Bjava.home%7D/lib/ext/jfxrt.jar, skipping
> >> >
> >> > I checked the manifest of module org-netbeans-libs-javafx.jar
> >> > And actually I found:
> >> > 
> >> > OpenIDE-Module-Requires: org.openide.modules.ModuleFormat1
> >> > Class-Path: %24%7Bjava.home%7D/lib/ext/jfxrt.jar
> >> >
> >> > Which is an url encoded string of ${java.hom}/lib/ext/jfxrt.jar
> >> >
> >> > I build on zulu8.58.0.13-ca-fx-jdk8.0.312-win_x64\jre\lib\ext
> >> > where jfxrt.jar exists... and JFX works in the application later. Just
> >> > wondering why such warning is generated.
> >> >
> >> > I suspect that the Maven checker is somehow not understanding properly
> >> this
> >> > classpath entry in the manifest.
> >> >
> >> > Any idea?
> >>
> >> The commit that changes this is here:
> >>
> >>
> >>
> https://github.com/apache/netbeans/commit/1b96b56ac3bfda8bd9b97f36c25901e84289cb23
> >>
> >> And is part of this:
> >>
> >> https://github.com/apache/netbeans/pull/2761
> >>
> >> The TL;DR version is (if I remember correctly): the JAR File
> >> Specification says, that the Class-Path attribute is a list of URLs and
> >> since javac 11 this is actually enforced.
> >>
> >> Try this:
> >>
> >> new URI("%24%7Bjava.home%7D%2F/lib/ext/jfxrt.jar");
> >> new URI("${java.home}/lib/ext/jfxrt.jar");
> >>
> >> It blows for the second line.
> >>
> >> Hope that clears it up.
> >>
> >> 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
> >>
> >>
> >>
> >>
>

Re: Log4J and its consequences for NetBeans and open source in general

[Jaroslav Tulach]

pá 14. 1. 2022 v 12:08 odesílatel Geertjan Wielenga 
napsal:

> Hi all,
>
> Some interesting reading:
>
> https://www.theregister.com/2022/01/13/opensource_apacheplc4x_payment/
>
>
> https://www.theregister.com/2021/12/14/log4j_vulnerability_open_source_funding/
>
> As established thus far, there is no impact on NetBeans for the log4j
> situation in terms of attack vectors, since NetBeans doesn't use v2 and the
> v1 scenario doesn't apply to NetBeans.
>
> However, there are other issues involved here, as described in the links
> above.
>
> When I see out of nowhere e-mails arriving here from addresses that we've
> never heard of, with domain names that are clearly large multinational
> enterprises, who we never hear of except now that there is potentially a
> security hole in the software they've been freeloading without contributing
> anything to, well, it's unacceptable. And we never hear from those e-mail
> addresses again after calming their concern, until the next time, etc.
>

+1


> For me personally, I may be arriving at a situation where I'm going to be
> ignoring e-mails clearly coming from corporations and (to avoid those
> people switching to gmail accounts) to people not participating at all
> other than raising issues and demanding immediate assistance and asking for
> help in one way or another.
>
> The choices you have are simple: pay money to a commercial provider or pay
> time to the open source projects you're using. Time does not mean filing an
> issue and it does not mean writing a mail voicing your frustration. It
> means responding to other people when they have questions and at least
> investigating the issue you're reporting since after all you're a developer
> on all of NetBeans is on GitHub for you to investigate.
>
> I'm not writing this on behalf of the PMC but just under my own name and
> title. :-)
>

Apply lazy consensus and publish an official NetBeans blog post!

Eric:
> link / ...  to provide a way of donations

FYI: https://www.apache.org/foundation/contributing.html
-jt

Re: [DISCUSS] Compiling against internal JDK classes was: Let's require NetBeans to be built with JDK11

[Jaroslav Tulach]

Hello Antonio,
I am changing the title to discuss usage of JDK internals.

> 1. Question I: "sun.awt/sun.swing" classes.

I suggest to avoid using the JDK internals as much as possible. E.g.

> B) comment/remove this jdk-internal specific features in NetBeans?

I'd encouraged you to rather create a pull request for OpenJDK project.
Small changes like https://github.com/openjdk/jdk/pull/3939 have a chance
to be integrated. Then NetBeans could rely on proper API rather than
continue to hack around JDK limitations.
-jt



pá 14. 1. 2022 v 8:26 odesílatel antonio  napsal:

> Hi all,
>
> Regarding the adoption of JDK 11 and the future stragety we want to
> follow, I have several questions:
>
> 1. Question I: "sun.awt/sun.swing" classes.
>
> We're using sun.awt and sun.swing classes in one "dlight" module we're
> receiving in the 4th/5th donation. This is because there is an
> implementation of BasicFileChooser for remote systems. These classes are
> _not_ exported in the new java.awt.desktop module.
>
> Do we want to:
>
> A) continue using these by adding some "--add-exports" to the build
> system to gain access to internal module classes?
>
> B) comment/remove this jdk-internal specific features in NetBeans?
>
> C) Use reflection (and possibly an "--add-opens", note this will have an
> ugly runtime dependency, not a build dependency).
>
> 2. Question II: Builds depend on the compiler, not the runtime.
>
> As Jaroslav points out in his email below, we're using Ant's " property/classname" ([2] for reference) in some places [1].
>
> This makes the build dependent on the version of our _compiler_, and not
> in on the version of our _target runtime_.
>
> Questions are:
>
> A) Is this correct? Do we want the build to depend on the version of our
> _compiler_?
>
> B) If not, do we want to add a:
> classpath="${nbjdk.bootclasspath}"
> property to these "available" Ant task so the build system depends on
> the target runtime?
>
> C) If so, is "nbjdk.bootclasspath" the correct property to use?
> "nbjdk.home" instead? Is there any other one? Do we want a new property
> "nb.target.jdk"?
>
>
> Any clarifications most welcome!
>
> Thanks,
> Antonio
>
>
> [1]
> A not exhaustive list:
>
> platform/applemenu:
>
> https://github.com/apache/netbeans/blob/d2ae8ba167c659458deca4a8cea3177af8450947/platform/applemenu/build.xml#L26
>
> nbi/engine:
>
> https://github.com/apache/netbeans/blob/d2ae8ba167c659458deca4a8cea3177af8450947/nbi/engine/build.xml#L74
>
> platform/openide.util.enumerations:
>
> https://github.com/apache/netbeans/blob/d2ae8ba167c659458deca4a8cea3177af8450947/platform/openide.util.enumerations/build.xml#L24
>
> ide/db:
>
> https://github.com/apache/netbeans/blob/d2ae8ba167c659458deca4a8cea3177af8450947/ide/db/build.xml#L30
>
>
> [2]
> https://ant.apache.org/manual/Tasks/available.html
>
> El 1/10/21 a las 16:44, Jaroslav Tulach escribió:
> >> I like this proposal in principle.
> >> In case i am missing something - what module would be a candidate for
> >> java.target=11 (as example)?
> >>
> > I see the applemenu module as a really nice example:
> >
> https://github.com/apache/netbeans/blob/master/platform/applemenu/build.xml#L26
> > it has two implementations of
> >
> https://github.com/apache/netbeans/blob/master/platform/applemenu/src/org/netbeans/modules/applemenu/NbApplicationAdapter.java
> > one is for JDK8 using some external binary Apple classes
> >
> https://github.com/apache/netbeans/blob/master/platform/applemenu/src/org/netbeans/modules/applemenu/NbApplicationAdapterJDK8.java
> > and the second is using official JDK9 API like `java.awt.desktop.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: [VOTE] Release Apache NetBeans VSCode extension 12.6.301

[Jaroslav Tulach]

+1 (binding)

Checked SHA signatures. Checked .asc signatures. Used the complementary
binary successfully. I also built from the source with (slightly changed
ant command) successfully:
```bash
$ ant build -Dmetabuild.branch=release1263 -Dmetabuild.jsonurl=
https://raw.githubusercontent.com/apache/netbeans-jenkins-lib/0f4c351e89e1945a
e440f53d0ac7c2ba9c0acae4/meta/netbeansrelease.json
$ cd java/java.lsp.server
$ ant build-vscode-ext -Dvsix.version=12.6.301 -D3rdparty.modules=none
-Dmetabuild.jsonurl=
https://raw.githubusercontent.com/apache/netbeans-jenkins-lib/0f4c351e89e1945ae440f53d0ac7c2ba9c0acae4/meta/netbeansrelease.json
```
A `.vsix` is created. I can install such `.vsix` into VSCode and use it on
my JDK 1.8.0_301.
-jt

čt 13. 1. 2022 v 9:30 odesílatel Martin Balin 
napsal:

> Dear community,
> let's update the Apache NetBeans Language Server extension on VSCode
> Marketplace with significantly improved version 12.6.301
>
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/12.6.301/
>
> The primary voting artifact is the source
>
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/12.6.301/apache-netbeans-java-12.6.301-src.zip
> built from branch ‘vsnetbeans_preview_1263`
> SHA-512 sum is:
>
> 574ef054fe1c792e3f090799122a7269af3fcebe916dc70f9421694fb340b18a94ecd38649ba6e19c5d26e3be339d87eaf431c3abf98cd35a18ac6d1c077134a
> and PGP signature:
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/12.6.301/apache-netbeans-java-12.6.301-src.zip.asc
>
> Binary artifacts were built by
> https://ci-builds.apache.org/job/Netbeans/job/netbeans-vscode/807/
>
> Use following commands to build your own 12.6.301 VSIX  binary:
>
> tmp$ unzip apache-netbeans-java-12.6.301-src.zip
> tmp$ ant build-source-config -Dmetabuild.branch=release1263
> -Dmetabuild.jsonurl=
> https://raw.githubusercontent.com/apache/netbeans-jenkins-lib/0f4c351e89e1945ae440f53d0ac7c2ba9c0acae4/meta/netbeansrelease.json
>
> tmp$ cd java/java.lsp.server
>
> java.lsp.server$ ant build-vscode-ext -Dvsix.version=12.6.301
> -D3rdparty.modules=none -Dmetabuild.jsonurl=
> https://raw.githubusercontent.com/apache/netbeans-jenkins-lib/0f4c351e89e1945ae440f53d0ac7c2ba9c0acae4/meta/netbeansrelease.json
>
> In addition to the source ZIP file, we are also voting about convenience
> binary:
>
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/12.6.301/apache-netbeans-java-12.6.301.vsix
> SHA-512
> 
> sum and signature are available next to binaries.
> The binary has been produced by the same job run #807, from the same
> commit.
>
> This vote is going to be open at least 72 hours, vote with +1, 0, and -1
> as usual. Please mark your vote with (binding) if you're an Apache NetBeans
> PMC member.
>
> Thank you,
> Martin Balín
>

Getting ready for VSNetBeans 12.6.301

[Jaroslav Tulach]

Hello.
As usually, we are in need to release `.vsix` VSCode extension preview
this/next week. This time we need to do that from a branch (just like it
was done for 12.4.301). I've created

https://github.com/apache/netbeans/tree/vsnetbeans_preview_1263

I'd like to ask Sváťa to integrate
https://github.com/apache/netbeans/pull/3414 into the branch - the
implementation is ready and we need it to make sure logical project view
icons look sexy enough, but the API is still being discussed. Sváťo
continue to polish the API then and let's get #3414 into the master branch
for NetBeans 13!

Jan Horváth shall remove DataBase explorer from the
`vsnetbeans_preview_1263` branch. The functionality isn't fully ready,
additional PRs are pending and we can live without it.

I plan to prepare the bits (from the branch) and start voting later this
week.
-jt

Re: Release 1.7.3 of NetBeans HTML/Java API

[Jaroslav Tulach]

Dne středa 22. prosince 2021 15:56:43 CET, Neil C Smith napsal(a):
> On Wed, 22 Dec 2021 at 14:27, Jaroslav Tulach  
wrote:
> > Dne pondělí 6. prosince 2021 16:39:40 CET, Neil C Smith napsal(a):
> > > On Sun, 5 Dec 2021 at 18:59, Jaroslav Tulach 
> > 
> > wrote:
> > > > The primary artifact is now at
> > > > https://dist.apache.org/repos/dist/release/netbeans/netbeans-html4j/ne
> > > > tbea
> > > > ns-html4j-1.7.3/
> > > 
> > > Please make sure to svn rm old releases of html4j (and vscode) when
> > > releasing.
> > 
> > I am always using `svn mv` when releasing. As far as I can tell the
> > https://dist.apache.org/repos/dist/dev/netbeans/netbeans-html4j/
> > is empty at revision 51703
> 
> Yes, I mean the old releases at
> https://dist.apache.org/repos/dist/release/netbeans/netbeans-html4j/
> 
> Only the current release (1.7.3) should still be there. eg. see
> https://dist.apache.org/repos/dist/release/netbeans/netbeans/  All
> previous releases are automatically archived - see
> https://archive.apache.org/dist/netbeans/netbeans/ or
> https://archive.apache.org/dist/netbeans/netbeans-html4j/
> 
> Please also see https://www.apache.org/legal/release-policy.html#archived

Interesting use of a versioning system.

Older releases are gone as of 51718:
https://dist.apache.org/repos/dist/release/netbeans/netbeans-html4j/

-jt




-
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 1.7.3 of NetBeans HTML/Java API

[Jaroslav Tulach]

Dne pondělí 6. prosince 2021 16:39:40 CET, Neil C Smith napsal(a):
> On Sun, 5 Dec 2021 at 18:59, Jaroslav Tulach  
wrote:
> > The primary artifact is now at
> > https://dist.apache.org/repos/dist/release/netbeans/netbeans-html4j/netbea
> > ns-html4j-1.7.3/
> Please make sure to svn rm old releases of html4j (and vscode) when
> releasing.

I am always using `svn mv` when releasing. As far as I can tell the
https://dist.apache.org/repos/dist/dev/netbeans/netbeans-html4j/
is empty at revision 51703

-jt






-
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

[RESULT][VOTE] Release 1.7.3 of NetBeans HTML/Java API

[Jaroslav Tulach]

The release has been approved:

+1 (binding):

- Dušan Bálek
- Toni Epple
- Jaroslav Tulach

+1 

- Martin Balín

The primary artifact is now at
https://dist.apache.org/repos/dist/release/netbeans/netbeans-html4j/netbeans-html4j-1.7.3/
The JARs were sent to Maven central.
-jt

Dne čtvrtek 2. prosince 2021 10:59:08 CET, Jaroslav Tulach napsal(a):
> Hello guys,
> I'd like to use Java and JavaScript interop in VSNetBeans[1] to display rich
> HTML UI dialogs, but I need few fixes first. As such, I need your approval
> to release new version of the Apache NetBeans HTML/Java API. The version
> 1.7.3 comes with better OSGi names, few bug fixes and some API
> enhancements. Please review the ZIP at
> 
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-html4j/netbeans-htm
> l4j-1.7.3/
> 
> the primary voting artefact has SHA512:
> 
> 15b482d5374d2257ed920a009f270dab7a2db9ea86e39cc94aa7aef7385cc74cc363a71fd13c
> a028b53443d19edd07258ffe3c386f31bed5462d8cb6a5ed05d2
> netbeans-html4j-1.7.3.zip
> 
> The bits have also been uploaded to staging Maven repository
> https://repository.apache.org/content/repositories/orgapachenetbeans-1093/
> and I am about to release them to Maven central if the vote passes.
> 
> The sources as well as the Maven bits are produced from
> https://github.com/apache/netbeans-html4j/tree/release-1.7.3
> tag in the main HTML/Java github repository.
> 
> Please test the new release in your project and cast your vote. Ideally I
> release by end of this week.
> -jt
> 
> [1] https://github.com/apache/netbeans/pull/3349





-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: [VOTE] Release 1.7.3 of NetBeans HTML/Java API

[Jaroslav Tulach]

+1 (binding)

I've updated my PR to use the 1.7.3 bits:
https://github.com/apache/netbeans/pull/3349/commits/7b53b632de5886904cdfa908b0e5f6713e4642ee
and it seems to work OKeyish:
https://app.travis-ci.com/github/apache/netbeans/builds/242922471 - some
failures are there, but presumably not related to the new HTML/Java bits.

-jt


čt 2. 12. 2021 v 10:59 odesílatel Jaroslav Tulach 
napsal:

> Hello guys,
> I'd like to use Java and JavaScript interop in VSNetBeans[1] to display
> rich
> HTML UI dialogs, but I need few fixes first. As such, I need your approval
> to
> release new version of the Apache NetBeans HTML/Java API. The version
> 1.7.3
> comes with better OSGi names, few bug fixes and some API enhancements.
> Please
> review the ZIP at
>
>
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-html4j/netbeans-html4j-1.7.3/
>
> the primary voting artefact has SHA512:
>
> 15b482d5374d2257ed920a009f270dab7a2db9ea86e39cc94aa7aef7385cc74cc363a71fd13ca028b53443d19edd07258ffe3c386f31bed5462d8cb6a5ed05d2
>
> netbeans-html4j-1.7.3.zip
>
> The bits have also been uploaded to staging Maven repository
> https://repository.apache.org/content/repositories/orgapachenetbeans-1093/
> and I am about to release them to Maven central if the vote passes.
>
> The sources as well as the Maven bits are produced from
> https://github.com/apache/netbeans-html4j/tree/release-1.7.3
> tag in the main HTML/Java github repository.
>
> Please test the new release in your project and cast your vote. Ideally I
> release by end of this week.
> -jt
>
> [1] https://github.com/apache/netbeans/pull/3349
>
>
>
>

[VOTE] Release 1.7.3 of NetBeans HTML/Java API

[Jaroslav Tulach]

Hello guys,
I'd like to use Java and JavaScript interop in VSNetBeans[1] to display rich 
HTML UI dialogs, but I need few fixes first. As such, I need your approval to 
release new version of the Apache NetBeans HTML/Java API. The version 1.7.3 
comes with better OSGi names, few bug fixes and some API enhancements. Please 
review the ZIP at

https://dist.apache.org/repos/dist/dev/netbeans/netbeans-html4j/netbeans-html4j-1.7.3/

the primary voting artefact has SHA512: 

15b482d5374d2257ed920a009f270dab7a2db9ea86e39cc94aa7aef7385cc74cc363a71fd13ca028b53443d19edd07258ffe3c386f31bed5462d8cb6a5ed05d2
  
netbeans-html4j-1.7.3.zip

The bits have also been uploaded to staging Maven repository
https://repository.apache.org/content/repositories/orgapachenetbeans-1093/
and I am about to release them to Maven central if the vote passes.

The sources as well as the Maven bits are produced from
https://github.com/apache/netbeans-html4j/tree/release-1.7.3
tag in the main HTML/Java github repository.

Please test the new release in your project and cast your vote. Ideally I 
release by end of this week.
-jt

[1] https://github.com/apache/netbeans/pull/3349




-
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: [java] - attach debugger - port - automatically remove leading and trailing whitespaces

[Jaroslav Tulach]

Hello Jan,
thanks for considering making NetBeans better!

> I have working a POC for that improvement. I added DocumentFilter for text
> fields in org.netbeans.modules.debugger.jpda.ui.ConnectPanel. It works fine.

Please create a pull request with your change at https://github.com/apache/
netbeans repository.
-jt




-
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: Re: [DISCUSS] Default to FlatLaf in NetBeans 13?

[Jaroslav Tulach]

NetBeans IDE was always keen on to work "out of the box" - e.g. as little
dialogs on 1st start as possible. If you want prior launch customization,
put it into installer.


čt 25. 11. 2021 v 20:37 odesílatel Eric Bresie  napsal:

> If the setup dialog is seen as useless then why not make it useful?
>
> I still think some additional customization wouldn’t be the end of the
> world. When setting up as I recall (see below link for specifics) there is
> the following dialogs:
>
> (1) customize dialog
> (1a) select specific packs/runtimes
>

That's is what the installer already does, right?


> (2) licenses
>

License is Apache. No need for any dialogs.


> (3) Netbean home and JDK home
>

Both have reasonable defaults.

(4) Summary/check for update
>

Check for update used to be done as the last step in installer. Keep it
there.


> For that matter could just as easily open up the Options to allow some
> customization and/or Plugins dialog during install?
>

Once the IDE is installed. You can ask it to do something (show options).
That's how the installer checks for updates - it asks the IDE to update
itself.


> For that matter IntelliJ allows look and feel customization at setup. It’s
> not completely unjustified.
>

While many treat that IDE as a "UI specification", I don't. In case of out
of box experience I'd rather eliminate as many options/dialogs/questions on
1st start as possible.
-jt