Re: [VOTE] Release Apache NetBeans 22

[Jakub Herkel]

[x] yes / +1
[ ] no / -1 (please justify -1)
[ ] binding (member of PMC)

My vote is based on

[ ] I have built and tested the source with  on  (required)
[x] I have tested the binary zip with OpenJdk 21/22 on Fedora Linux
[ ] I have tested the  installer(s) with  on 
[ ] I have tested the Maven artefacts
[ ] I have tested the VSCode extension

Jakub Herkel

On Sun, May 26, 2024 at 7:13 AM Junichi Yamamoto  wrote:
>
> [X] yes / +1
> [ ] no / -1 (please justify -1)
> [X] binding (member of PMC)
>
> My vote is based on
>
> [X] I have built and tested the source with OpenJDK 17 on Uubuntu
> 22.04 (required)
> [ ] I have tested the binary zip with  on 
> [X] I have tested the deb installer with OpenJDK 17 on Ubuntu 22.04
> [ ] I have tested the Maven artefacts
> [ ] I have tested the VSCode extension
>
> Thanks a lot,
> Junichi
>
> On Thu, May 23, 2024 at 11:43 PM Eric Barboni  wrote:
> >
> > This is our first voting candidate for the release of Apache NetBeans 22.
> >
> > Please follow the voting template at the bottom of this email, and note all 
> > requirements
> > below for validating sources and convenience binaries before voting.
> >
> > Apache NetBeans 22 constitutes all clusters in the Apache NetBeans Git 
> > repository,
> > which together provide the NetBeans Platform (i.e., the underlying 
> > application framework),
> > as well as all the modules that provide the Java SE, Java EE, PHP, 
> > JavaScript and Groovy
> > features of Apache NetBeans.
> >
> > 
> >
> > Build artefacts are available here :
> > https://dist.apache.org/repos/dist/dev/netbeans/netbeans/22/
> >
> > They were built by the Jenkins pipeline :
> > https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/release220/14/
> >
> > 
> > We are primarily voting on :
> > https://dist.apache.org/repos/dist/dev/netbeans/netbeans/22/netbeans-22-source.zip
> > SHA512 :
> > 636cad619bc316a76f04ba0e92b6669b9d9052e28695020e95ad38dbc1d4647e346a91f1c7314dffdda384178a22d3f4fa64fcb7ddf75ab29fed2e528840
> >
> > KEYS file : https://downloads.apache.org/netbeans/KEYS
> > 
> >
> > Associated with the primary source item we have, generated with the 
> > pipeline mentioned above :
> >
> > -- at https://dist.apache.org/repos/dist/dev/netbeans/netbeans/22/
> >
> > Binaries associated with the source - netbeans-22-bin.zip as well as update 
> > content under the nbms folder.
> >
> > -- at 
> > https://dist.apache.org/repos/dist/dev/netbeans/netbeans-installers/22/
> >
> > A PKG installer for macOS built and signed with NBPackage on a PMC member's 
> > macOS machine.
> > An EXE installer for Windows signed by a PMC member using binaries created 
> > during the build process.
> > DEB and RPM packages for Linux signed by a PMC member using binaries 
> > created with NBPackage during the build process.
> >
> > -- at 
> > https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/22.0/
> >
> > The VSCode extension signed by a PMC member using binaries created during 
> > the build process.
> >
> >
> >
> > Maven Artefacts
> >
> > The Maven artefacts for Apache NetBeans 22 are staged at :
> >
> > https://repository.apache.org/content/repositories/orgapachenetbeans-1144/
> >
> > The version is : RELEASE220
> >
> > 
> >
> > 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 may check the associated
> > convenience binary zip, installers, nbms and maven staging at the links
> > above. You are not expected to check ev

Re: [VOTE] Release Apache NetBeans 20

[Jakub Herkel]

[x] yes / +1
[ ] no / -1 (please justify -1)
[ ] binding (member of PMC)

My vote is based on

[ ] I have built and tested the source with  on  (required)
[x] I have tested the binary zip with  openjdk 17 and 21 on Fedora Linux 39
[ ] I have tested the  installer(s) with  on 
[ ] I have tested the Maven artefacts
[ ] I have tested the VSCode extension

with best regards

Jakub

On Tue, Nov 28, 2023 at 10:47 AM Eric Barboni  wrote:
>
> This is our first voting candidate for the release of Apache NetBeans 20.
>
> Please follow the NEW voting template at the bottom of this email,
> and note all requirements below for validating sources and convenience
> binaries before voting.
>
> Apache NetBeans 19 constitutes all clusters in the Apache NetBeans Git
> repository,
> which together provide the NetBeans Platform (i.e., the underlying
> application framework),
> as well as all the modules that provide the Java SE, Java EE, PHP,
> JavaScript and Groovy features of Apache NetBeans.
>
> 
>
> Build artefacts are available here :
>
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans/20/
>
> They were built by the Jenkins pipeline :
>
> https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/release200/16
> /
>
> 
>
> We are primarily voting on :
>
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans/20/netbeans-20-sour
> ce.zip
>
> SHA512 :
> e795875918022541354213b03d7c4515db81c384f43d0b87029666583064e3093ca1a6ebe8f6
> ffa633c62d02a551be8df52703dfefb830efb8654558ddec5f28
>
> KEYS file : https://downloads.apache.org/netbeans/KEYS
>
> 
>
> Associated with the primary source item we have, generated with the
> pipeline mentioned above :
>
> -- at https://dist.apache.org/repos/dist/dev/netbeans/netbeans/20/
>
> Binaries associated with the source - netbeans-20-bin.zip as well as
> update content under the nbms folder.
>
> -- at
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-installers/20/
>
> A PKG installer for macOS built and signed with NBPackage on a PMC member's
> macOS machine.
> An EXE installer for Windows signed by a PMC member using binaries created
> during the build process.
> DEB and RPM packages for Linux signed by a PMC member using binaries created
> with NBPackage during the build process.
>
> -- at
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/20.0/
>
> The VSCode extension signed by a PMC member using binaries created during
> the build process.
>
>
>
> Maven Artefacts
>
> The Maven artefacts for Apache NetBeans 20 are staged at :
>
> https://repository.apache.org/content/repositories/orgapachenetbeans-1137/
>
> The release of maven artefacts is based on a secondary build at
> https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/release200/17
> / changing only the plugin nb-repository-plugin that was not populating
> pom.xml
>
> The version is : RELEASE200
>
> 
>
> 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 may check the associated
> convenience binary zip, installers, nbms and maven staging at the links
> above. You are not expected to check every convenience binary.
>
> 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.
>
> 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 as binding only if you're an Apache NetBeans
> PMC member to help with voting admin.
>
> Only respond if you are going to vote - this is NOT a discussion thread.
>
> Apache NetBeans 20 will be released if and when this vote passes.
>
> ---
>
> Voting template
>
> Please copy and paste the answer form below into your email. Fill the
> checkboxes as appropriate (eg. [X]). Replace ,  and  as
> appropriate.
>
> -- Answer form 
>
> [ ] yes / +1
> [ ] no / -1 (please justify -1)
> [ ] binding (member of PMC)
>
> My vote is based on
>
> [ ] I have built and tested the 

Re: [DISCUSS] maven remote repo indexer improvements

[Jakub Herkel]

I would like to ask you if there is (will be) some configuration
option (via property for example) in which directory remote index
processing is?
I have a problem on my notebook that all processing is in /tmp
directory (tmpfs) with size 8GB and it always stops with an out of
space exception. And it is little bit awkward if every opening of
pom.xml results in downloading remote index and processing it with no
success.

best regards

jakub

On Tue, Apr 18, 2023 at 9:11 PM Michael Bien  wrote:
>
> my thoughts so far on how I wanted to implement it:
>
>   - time cutoff filter would be optional, configurable in the usual
> maven/indexer options. Quick tests showed that full/2years/1year might
> be reasonable values
>
>   - sha1 filter would be applied by default, this cuts index size in
> half and currently no NB feature is running sha1 queries, this would be
> also a candidate for substitution via a online service - if we really
> don't need it we deprecate the queries. Hashes compress badly.
>
>   - multi threaded extraction would be optional, potentially enabled by
> default. This has a slight index size penalty due to merge overhead, so
> I don't want to enable this without filters. Second concern are molten
> notebooks, some are not made for sustained load and might prefer to run
> the task in the background for 15mins instead of 6mins with loud fans.
>
>
> the first query which is planned to be augmented by a online service is
> class name search. Since this data wasn't in the index anymore for years
> (nobody noticed though?).
>
> and yeah index updates should run faster. But this is on the bottom of
> the todo list - low hanging fruits first :)
>
>
> best regards,
> michael
>
>
> On 18.04.23 20:36, Matthias Bläsing wrote:
> > Hi,
> >
> > Am Dienstag, dem 18.04.2023 um 07:48 +0200 schrieb Jan Lahoda:
> >> I apologize for being contrarian, but since the index download
> >> started for me (again) while on a bus with very poor internet
> >> connection, I guess I should tell you my view.
> > no reason to apologize.
> >
> >> Unless I am mistaken, the index gz has currently roughly 1.9GB, and
> >> it tooks several minutes to actually create the Lucene index from it,
> >> consuming some more space and CPU.
> >>
> >> To be honest, it never seemed very polite to me to download and
> >> process so much without asking.
> >>
> >> I guess alternatives that I would see would include (combination of
> >> options possible):
> >> - explicitly ask before downloading (possibly allowing the user to
> >> select auto-download)
> > Yes, if people get notified, that they'll get the full index locally,
> > then I'm okk with that. I see a problem if features silently give
> > outdated answers or don't work at all. Else we'll get "NetBeans
> > suggested version X, but Y is already on central, why is this not
> > current?".
> >
> >> - have the features that use the index do some query on a server, if
> >> there isn't a downloaded index (or if it is stale/obsolete)
> > IMHO this highly depends on the speed of the API. If the latency is
> > high, the next bug will be "It takes ages until my POM tells me, that
> > it is outdated".
> >
> >> - given that https://github.com/apache/netbeans/pull/4999 produces a
> >> smaller index, we could have a download location (server) at least
> >> for maven central that would serve this optimized index. If I
> >> understand it properly, the smallest index under that PR is 0.8GB,
> >> and if it would compress reasonably well, it might be (say) 0.5GB
> >> compressed - much better than 1.9GB, and no significant CPU usage
> >> after the index is downloaded. (Even if it was 0.8GB, it is still
> >> much better than 1.9GB+CPU churn.)
> > Truncating the index needs to be done carefully. NetBeans has a search
> > my SHA1 (or MD5?) feature. That will break, if you remove that data
> > from the index. A similar situation will arise, if arbitrary cut offs
> > are done based on time. Consider a libary, that does some interesting
> > algorithm, that just works the same even after years. If we cut the
> > index at 6 months for example, that artifact won't be found anymore.
> >
> >> There was also an argument on conserving the ASF resources in another
> >> discussion recently. If I consider there would be (only) 10 000
> >> installations of NetBeans, with the default setting to download the
> >> index once a week, it is almost 20TB of data every week if I count
> >> correctly. +the CPU cycles to convert the index on user's machines.
> >> It seems there may be a way to conserve the ASF resources and provide
> >> better experience to the users at the same time.
> > The download is from sonatypes CDN. Given that they actively discourage
> > central mirrors, I have not to much concern here. It is also the the
> > resourced of the ASF.
> >
> > Greetings
> >
> > Matthias
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> > 

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

[Jakub Herkel]

+1

On Tue, Apr 11, 2023 at 11:13 AM Alexander Kronenwett
 wrote:
>
> +1
>
> Neil C Smith  schrieb am Di., 11. Apr. 2023, 10:17:
>
> > # Proposed policy
> >
> > * Apache NetBeans 18 will be the last release to support running the
> > platform on JDK 8.
> >
> > * From Apache NetBeans 19, the minimum JDK required to build and run
> > the IDE or platform will be JDK 11.
> >
> > * Future releases will take an "LTS-1" strategy for building and
> > running (and CI testing) of the IDE and platform. Three JDKs will be
> > supported at any one time - the current JDK, plus the previous two LTS
> > releases. eg. NetBeans 20 and 21 (Nov 2023 / Feb 2024) will support
> > JDK 11, 17 and 21. NetBeans 22 (May 2024) will support JDK 17, 21 and
> > 22.
> >
> > ## Background
> >
> > The Apache NetBeans IDE has officially required JDK 11 to build and
> > run since NetBeans 13 in March 2022. The platform (and unofficially
> > the IDE) have continued to support running on JDK 8 - all modules
> > requiring a higher JDK must currently be optional. Various tests have
> > continued on JDK 8.
> >
> > This situation is causing issues as workarounds must be found for
> > currently non-optional features that have dependencies or other
> > requirements for running on a higher JDK (eg. Maven indexing / Lucene
> > [1]). It's causing delays, complications and missed testing time in
> > integration of new features (eg. problems merging support for EE 10
> > [2]). Supporting an increasing range of JDKs is causing increasing
> > workload, both for people and CI. Meeting the challenges of deprecated
> > (for removal) features in the JDK is also complicated by the
> > additional JDK requirements.
> >
> > ## Notes
> >
> > * Apache NetBeans users will continue to be recommended to use the
> > current or latest LTS JDK to run the IDE.  The IDE will continue to
> > support users developing projects for/with JDK 8, for as long as
> > nb-javac and other dependencies allow.
> >
> > * This proposal specifically doesn't address when the default bytecode
> > level across the codebase is increased. This can happen when required,
> > but non-optional modules would be free to adopt the minimum JDK as
> > they need to.
> >
> > * Optional modules may continue to require a runtime JDK higher than
> > the minimum.  Should it become necessary, build time optional modules
> > might be considered - eg. a build on the minimum JDK may exclude
> > modules that will not run on that JDK at runtime.
> >
> > * Some modules that are of independent use (eg. lookup, utilities,
> > etc.) might be nominated and advertised to continue JDK 8 support for
> > the time being. This is not expected to cover the runtime container as
> > a whole - https://netbeans.apache.org/tutorials/nbm-runtime-container.html
> >
> > * Once NetBeans 19 is released, the NetBeans 18 release branch could
> > be used to backport and release JDK 8 supporting fixes, subject to any
> > PMC members wanting to manage those releases.
> >
> > * The term "platform" is used in reference to the whole framework of
> > modules that we release (eg. via Maven), not just the platform
> > cluster.
> >
> > [1] https://github.com/apache/netbeans/pull/4999
> > [2] https://github.com/apache/netbeans/pull/4692
> >
> >
> > ## Procedure
> >
> > This vote is going to be open at least 72 hours.  Vote with +1, 0, and -1.
> >
> > Please mark your vote as binding only if you're an Apache NetBeans PMC
> > member to help with voting admin.
> >
> > Decision will be by majority vote, with at least 3 binding positive votes.
> >
> > Thanks,
> >
> > Neil
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> > For additional commands, e-mail: dev-h...@netbeans.apache.org
> >
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >
> >
> >
> >

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

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

Re: Rust, anyone?

[Jakub Herkel]

Antonio, is there any list of things that you want (need) to
implement? Maybe someone (me also) can take some of them.

Jakub

On Mon, Feb 13, 2023 at 8:08 AM John Kostaras  wrote:
>
> Hello there. There has already been something about Rust
>  (written
> in JavaCC).
>
> Ioannis.
>
>
> On Sun, Feb 12, 2023 at 10:18 AM Antonio  wrote:
>
> > Thanks Michael!
> >
> > D'oh! My intents to add Rust to the NetBeans core (very much as in the
> > Linux kernel case) have been detected! :-D
> >
> > Latest commits solve these issues, though (and add new bugs).
> >
> > Next challenge: Cargo workspaces [1].
> >
> > Cheers,
> > Antonio
> >
> > [1] https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html
> >
> > On 12/2/23 9:03, Michael Bien wrote:
> > > for others who want to give it a try: I had to fix two things to make
> > > the build pass:
> > >   - removed references of RustPackage in org.openide.nodes.Node
> > > (probably a happy coding accident)
> > >   - had to create this folder: netbeans/rust/rust.project/test/unit/src
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> > For additional commands, e-mail: dev-h...@netbeans.apache.org
> >
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >
> >
> >
> >

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

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

Re: [RELEASES] Preparing for NetBeans 14

[Jakub Herkel]

Hi all,

I would like to ask if there is a possibility to include
NETBEANS-1309? Because now netbeans minimal java version is 11, this
PR can be simplified. But before any further steps from my side  I
want to know If someone would be able to review it afterwards.

Jakub

On Mon, Apr 11, 2022 at 3:42 PM Neil C Smith  wrote:
>
> Hi all, but particularly Geertjan, Eric and Martin!
>
> It's getting near that time again already!  Freeze and branch is
> scheduled for the end of this week.  As mentioned previously, I'm
> going to have to sit most of this one out due to other commitments
> from week commencing 25th.
>
> I could do notices, initial branches / configuration and first RC
> build before then though if you want me to pick that up?  Perhaps we
> freeze end of day on 19th, and I can run the builds, etc. on 20th?
>
> Weekly RC builds and the vote will have to be someone else.  I might
> be able to help out on PR reviews and merging to delivery - we should
> share that process out more anyway!  The whole delivery branch /
> syncing process might benefit from a bit better documentation too.
> Just been looking at the release readme, and realised some things are
> a bit behind current processes - will try and edit this week.
>
> I've just added the missing NB15 milestone too so PRs / issues can be
> punted forward where needed.
>
> Best wishes,
>
> Neil
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>

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

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

Re: [NOTICE] Last PRs for Apache NetBeans 12.4 Beta

[Jakub Herkel]

Maybe these two PR could be included (but they need final review & approval):

https://github.com/apache/netbeans/pull/2544
https://github.com/apache/netbeans/pull/2612

best regards

Jakub

On Thu, Apr 1, 2021 at 1:12 PM Tomáš Procházka  wrote:
>
> Would it be possible to review https://github.com/apache/netbeans/pull/2772 
> which makes PHP Annotation API public?
> It will allow to implement support for more annotations than only those in 
> listed friend modules.
>
> Regards,
> Tom
>
>
> On 01. 04. 21 11:45, Geertjan Wielenga wrote:
> > Hi all,
> >
> > Your brave release managers (the undersigned and Neil C. Smith), will
> > according to our schedule tomorrow put together a Beta release for 12.4,
> > including a vote thread once the sources and convenience binaries are
> > available.
> >
> > That means that, please:
> >
> > 1. This is a last call for PRs to be included in Beta.
> >
> > 2. Tomorrow we'll stop merging while release124 branch is created.
> >
> > 3. The current delivery branch will be deleted and a new one will be
> > created on feature freeze.
> >
> > Feel free to respond with any concerns or questions or any PRs that are not
> > merged yet that need to not be forgotten about.
> >
> > Thanks,
> >
> > 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
>
>
>

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

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

Re: Two paths to access Javac ASTs was: Access to Tag.getSummary()

[Jakub Herkel]

Thanks for clarification

jakub

On Tue, Mar 9, 2021 at 11:46 AM Jaroslav Tulach
 wrote:
>>
>> Well  it means there still will be a possibility to choose from two
>>
>> paths?
>
>
> `nb-javac` is licensed as GPLv2 with Classpath Exception - ASF doesn't like 
> to distribute GPLv2 software. Apache software shall not have a non-avoidable 
> non-system dependency on GPL software. Luckily there is `javac` in the JDK 
> (where JDK is considered a system dependency) and NetBeans can use it. Alas, 
> that implies two paths:
> - use latest JDK with its javac
> - use older JDK and nbjavac
>
> At least that's the current situation. My work on automatic backporting of 
> `nbjavac` doesn't try to change the current setup. It just makes the 
> differences between latest JDK `javac` and latest `nb-javac` as small as 
> possible.
>
> Best regards.
> -jt
>
>
>> One with the new nb-javac and the second with a javac from JDK
>> installation? My thinking about new nb-javac was like:
>> we will always install nb-javac and independently from current JDK we
>> will be able to parse the latest language features (depends on version
>> of nb-javac).
>> Because from my point of view if we internally depend on
>> com.sun.source and there is a difference between what we can use
>> during compilation of netbeans sources and what we get during parsing
>> there still will be a "problem" for implemention of new language
>> features. I think there could be a parity between
>>  parser and abstract syntax tree. So if our parser for example for
>> netbeans 14 is able to parse java sources for Java 17 we can also use
>> this AST in sources. Without any introspection (like in my code). I
>> know maybe I'm looking too far but is there a plan how to solve this?
>>
>> Jakub
>>
>> On Mon, Mar 8, 2021 at 11:44 AM Jaroslav Tulach
>>  wrote:
>> >
>> > Hello Jakub.
>> > Your inquiry isn't really related to "new vs. old" `nbjavac` as far as I 
>> > can
>> > tell, but to what API we compile against. Please see
>> >
>> > https://github.com/apache/netbeans/pull/2783
>> >
>> > If that PR got accepted, then (I believe) the new "summary" class/method
>> > would be available in the API for you to compile against. That's the pro. 
>> > On
>> > the cons side, the change proposed in #2783 would very likely mean NetBeans
>> > Java support would require `nbjavac` on any JDK<15. I am not sure our 
>> > project
>> > is ready to make such switch.
>> >
>> > Best regards.
>> > -jt
>> >
>> > Dne pondělí 8. března 2021 10:44:49 CET, Jakub Herkel napsal(a):
>> > > I would like to clarify one thing for me. If I understand correctly
>> > > with this new nb-javac we will have only one parser for java sources.
>> > > That is superb news (I have had/have lot of problems with parsing,
>> > > exceptions,...)
>> > > but I still see another problem here (but maybe I missed something) :
>> > > When I tried to fix some issues I had to write some ugly code
>> > > (NETBEANS-1309): switch(tag.getKind().name()) {
>> > > case "SUMMARY" :
>> > > try {
>> > > Method getSummaryMethod =
>> > > tag.getClass().getDeclaredMethod("getSummary");
>> > > List summaryList =
>> > > (List)getSummaryMethod.invoke(tag);
>> > > sb.append(inlineTags(summaryList,
>> > > docPath, doc, trees, null));
>> > > } catch(NoSuchMethodException |
>> > > SecurityException | IllegalAccessException | IllegalArgumentException
>> > >
>> > > | InvocationTargetException ex) {
>> > >
>> > > // IGNORE
>> > > }
>> > > break;
>> > >
>> > > Problem here is that code in the netbeans depends on
>> > > com.sun.source.doctree.* classes. But because we need to compile also
>> > > with JDK8 we don't have access to new features (for this fix a new
>> > > @Summary tag). Could this new nb-javac also help us
>> > > with type of "hack"?
>> > >
>> > > jakub
>> > >
>> > > On Sun, Mar 7, 2021 at 7:39 PM Jaroslav Tulach
>> > >
>> >

Re: Let's learn to love (the new) nb-javac! was: Everybody (else) seems to hate nb-javac!

[Jakub Herkel]

I would like to clarify one thing for me. If I understand correctly
with this new nb-javac we will have only one parser for java sources.
That is superb news (I have had/have lot of problems with parsing,
exceptions,...)
but I still see another problem here (but maybe I missed something) :
When I tried to fix some issues I had to write some ugly code (NETBEANS-1309):
 switch(tag.getKind().name()) {
case "SUMMARY" :
try {
Method getSummaryMethod =
tag.getClass().getDeclaredMethod("getSummary");
List summaryList =
(List)getSummaryMethod.invoke(tag);
sb.append(inlineTags(summaryList,
docPath, doc, trees, null));
} catch(NoSuchMethodException |
SecurityException | IllegalAccessException | IllegalArgumentException
| InvocationTargetException ex) {
// IGNORE
}
break;

Problem here is that code in the netbeans depends on
com.sun.source.doctree.* classes. But because we need to compile also
with JDK8 we don't have access to new features (for this fix a new
@Summary tag). Could this new nb-javac also help us
with type of "hack"?

jakub

On Sun, Mar 7, 2021 at 7:39 PM Jaroslav Tulach
 wrote:
>
> Hi.
> After enumerating the `nb-javac` deficiencies (below) and writing a plan to
> address them at our wiki https://cwiki.apache.org/confluence/display/NETBEANS/
> Overview%3A+nb-javac I am here with implementation of the automatic conversion
> of JDK16(!, yes we are half a year ahead the plan!) `javac`. Please join me in
> reviewing and discussing the consequences for NetBeans here or in the PR#12:
>
> https://github.com/oracle/nb-javac/pull/12
>
> Manually written nb-javac is dead. Long live the new nb-javac!
> -jt
>
> On Dec 18, 2020 [I wrote](https://lists.apache.org/thread.html/
> r5f210c99b0926aeaac2d0c3c419ff4b79e01f15b67c5ddcf32a51bbe%40%3Cdev.netbeans.apache.org%3E):
>
> > Hi.
> > First and foremost. I admire the work Arvind & his team are doing while
> > maintaining [nb-javac](http://github.com/oracle/nb-javac). I am sure they
> > don't hate it. Neither do I, but let's talk about the rest of us who have
> > some concerns...
> >
> > > Our love and hate relationship to nb-javac needs to be resolved. We
> > > suggest people to go without it, then we suggest people to try that.
> > > Also with the current release we see an increased amount of NPE-s and
> > > parsing errors.
> > >
> > >
> > > Two directions of thinking:
> > > 2. we need to get rid of nb-javac.
> > > #2 is a long term (~ a year) thing. I've been discussing possible ways
> > > to implement #2 and I think it can be done,
> > > if JDK's javac is improved with currently missing IDE-friently
> >
> > capabilities.
> >
> > > More on that in a separate email later.
> >
> > OK, this is the email. Let's enumerate the "haters":
> >
> > - Apache doesn't like `nb-javac` as it is GPLv2+CPEx component and those
> > are hard to distribute
> >- it would be way easier to use plain `javac` from a JDK
> >- distribution is problematic - needs internet connection and nb-javac
> > isn't yet on Maven central
> > - testers hate `nb-javac` as it multiplies the matrix of things to test
> >- each JDK needs to be tested twice - with `nb-javac` and without
> > `nb-javac`
> >- with every bug/problem one needs to know whether `nb-javac` was or
> > wasn't in use
> >- recent version `nb-javac-15` isn't really stable, see complains on the
> > mailing list
> > - maintainers of JDK's `javac` hate `nb-javac` because it is a fork of
> > their own work
> >- nobody likes forks
> >- ironically Arvind's team is part of JDK organization - e.g. it
> > maintains own fork of JDK's `javac`
> >
> > Clearly there are numerous drawbacks and we need a way out. Let's get rid
> > of `nb-javac` as we know it. Let's replace it with JDK's own `javac`!
> > Great, right? But there are problems...
> >
> > - `javac` in JDK15 isn't good enough
> >- compile on save doesn't work
> >- re-compilation of a single method doesn't work
> >- runs out of memory more often than `nb-javac`.
> >
> > Before we can get rid of `nb-javac`, we need to be sure `javac` in JDK is
> > good enough. I let Jan Lahoda (a JDK engineer working on `javac`) comment
> > and solve(!) this somehow. Let's now assume JDK17 offers good enough
> > `javac`, now we:
> >
> > - suggest people to use JDK17 when using Apache NetBeans IDE
> >- not a big problem, JDK17 is LTS, but then?
> >- if people wanted to use language features of JDK19, they'd have to run
> > on 19!
> >- that's not what competition does - they support latest language
> > features running on JDK11 LTS or even JDK8 LTS
> >
> > The story may end here and it can be a good enough story for Apache
> > NetBeans IDE. However, I don't like it. It is not good enough story yet. I
> > & 

Re: build 12.3-beta3 from source JShell could not be initialized

[Jakub Herkel]

I tried fresh beta 3 installation with JDK 11 and it works for me. But
when I imported settings from a previous installation  (lot of open
projects in my case) for the first time I had to wait for the first
JShell initialization for a long time (maybe there is some
interference with project scanning?). All next opening of JShell took
maybe 1 second.

Jakub

On Fri, Feb 19, 2021 at 12:32 PM Jeremy Cavanagh
 wrote:
>
> Hi All,
>
> Hope everyone is keeping safe and healthy.
>
> I've succeeded again building from source with jdk11 and everything
> seems fine except JShell. It doesn't initialize when running NetBeans on
> jdk11 or jdk15. Is it supposed to?
>
> Regards
>
> Jeremy
>
> -
> 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

NETBEANS-719 Saving configuration in a Attach debugger window

[Jakub Herkel]

I would like to know if there will by any interest in this feature. For me,
I often switch between C++ and Java. Also from time to time I need to debug
remotely. So from my point of view it would be nice to have a possibility
to save my debugger configuration. But as this is my personal wish and
because this window is used frequently (I think) I would like to have
another opinions before I start working on this task.

jakub

Re: How to use different versions of javac api in netbeans sources

[Jakub Herkel]

Is there really nobody who could have any advice?

jakub

On Mon, Nov 9, 2020 at 6:06 PM John Neffenger  wrote:

> On 11/9/20 12:34 AM, Jakub Herkel wrote:
> > These tags are parts of Java Compiler API. So for Java 10+ there is a new
> > SUMMARY tag.
>
> While we're at it, there's also a handy new Javadoc tag for system
> properties, available in Java 12, that I've noticed is missing in NetBeans:
>
> JEP draft: Guidelines for documenting system properties
> https://openjdk.java.net/jeps/8214497
>
> More details are in the Compatibility & Specification Review below:
>
> Support {@systemProperty } tag
> https://bugs.openjdk.java.net/browse/JDK-8211132
>
> John
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

How to use different versions of javac api in netbeans sources

[Jakub Herkel]

Hi,

I checked this issue https://issues.apache.org/jira/browse/NETBEANS-1309.
This issue is about a new javadoc @summary tag and that Netbeans doesn't
display any summary when this tag is used in javadoc popup.
I debugged source code and, if I am correct, data for this javadoc popup
are generated in ElementJavadoc class (Java Source UI module). There is a
code :
 for (DocTree tag : tags) {
switch (tag.getKind()) {
case REFERENCE:
ReferenceTree refTag = (ReferenceTree)tag;
appendReference(sb, refTag, null, docPath, doc, trees);
break;
...
 case TEXT:
TextTree ttag = (TextTree)tag;
sb.append(ttag.getBody());
}

These tags are parts of Java Compiler API. So for Java 10+ there is a new
SUMMARY tag.
But as far as I know Netbeans is compiled with Java 8, so I don't have
access to it. Is there a way how I can use a newer version of Java Compiler
API with Netbeans? Or any hint of what I can do in this issue?

Jakub

Re: can I disable gradle support on my project?

[Jakub Herkel]

In the past I did some investigation about this bug (1802). I was able to
collect all type of projects (maven,web,...) that we can use for switching.
But later I have found problem that not all of these collected projects are
"real". Some of them are only thin wrappers that are able to detect if type
of project is supported and ask user for installing a "real" pluging. So is
there any API that we can use for a detection of this type of plugin?

On Mon, Jul 29, 2019 at 8:48 AM Laszlo Kishalmi 
wrote:

> Watch this one: https://issues.apache.org/jira/browse/NETBEANS-1802
>
> And this one: https://github.com/apache/netbeans/pull/1403
>
>
> On 7/26/19 10:09 PM, Wade Chandler wrote:
> > A big thing for us to keep in mind for the future of NB IMO is that
> Gradle,
> > Ant, Make, Cake, Gulp etc are actually build automation tools which give
> a
> > standardized mechanism to build and execute nearly anything; not just
> Java,
> > C/C++, .Net, or JS respectively. A team can use these to get standardized
> > builds or automated processes, and this then means they will use one of
> > these tools along with other build related tools and technology stacks;
> > Gradle itself has native C++ build features built in.
> >
> > We use Gradle to build and test Python and Docker images as an example.
> > There are npm and node plugins for Gradle that will help similar to
> Gradle
> > wrapper in that they download the needed versions of those things and
> don't
> > mess with the global environment to help teams using different OSes and
> > mixed environments have more stable node builds.
> >
> > This is great stuff, but it does mean there are mixed technology projects
> > where requirements.txt, package.json, and build.gradle all reside in the
> > same top level places, and as such we need some mechanism in NB to allow
> > context switching or some how have all required options available all the
> > time for a single location versus thinking of a location as a single tech
> > stack project as we do atm.
> >
> > Wade
> >
> > On Thu, Jul 25, 2019, 13:00 Laszlo Kishalmi 
> > wrote:
> >
> >> I'm just curious, how do you use Gradle in a PHP project?
> >>
> >> Is there a good commonly used PHP plugin for Gradle?
> >>
> >> I'm asking as it might be reasonable to integrate the PHP with Gradle in
> >> NetBeans, so instead of disabling the Gradle support you would get the
> >> features both from PHP and Gradle.
> >>
> >> On 7/24/19 8:10 AM, Emilian Bold wrote:
> >>> No, we have an issue about this (mixed projects) but no solution yet.
> You
> >>> can only rename files or do something to disable a folder from being
> >>> detects as a project type.
> >>>
> >>> --emi
> >>>
> >>> mie., 24 iul. 2019, 16:50 Jake Ochs  a scris:
> >>>
>  cross posting this on users & dev...
> 
>  I have a large PHP project that also has gradle projects in it. The
>  problem is that in NB11, it seems that the gradle nature overrides the
> >> PHP
>  nature and breaks some PHP features such as "open in project" and
> >> clicking
>  on a class to go to the source (sometimes.) Can I disable the gradle
> >> nature
>  of the project or force the PHP behavior?
> 
> >> -
> >> 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
>
>
>
>