Re: [VOTE] Release Apache NetBeans 23
[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 64-Bit Server VM Corretto-17.0.5.8.1 on Ubuntu 22.04 amd64 (required) [X] I have tested the binary zip with OpenJDK 64-Bit Server VM Corretto-17.0.5.8.1 on Ubuntu 22.04 amd64 [ ] I have tested the installer(s) with on [ ] I have tested the Maven artefacts [ ] I have tested the VSCode extension I opened some projects and built them. Everything works fine. Thank you and congratulations! On 16/9/24 11:28, Eric Barboni wrote: This is our first voting candidate for the release of Apache NetBeans 23. 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 23 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. - 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] Releasing of nbm-archetype 1.19 netbeans-platform-app-archetype 1.24
+1 (binding) - checked sigs and SHA512 - eyeballed LICENSE, NOTICE Thanks! Antonio On 6/8/24 14:15, Eric Barboni wrote: Dear members of Apache NetBeans community. I want to call a vote on releasing the following Apache NetBeans Archetypes 1) nbm-archetype-1.19 2) netbeans-platform-app-archetype-1.24 Apache Maven Archetypes are used by Apache NetBeans in the project wizard "Java With Maven" to create NetBeans Module and NetBeans Application - Archetype used plugin are up to date, java 8 minimum like previously. The voting artefacts sources are respectivly located here: 1) https://dist.apache.org/repos/dist/dev/netbeans/netbeans-maven-archetypes/nbm-archetype/nbm-archetype-1.19/ sha512 5ba836723105bb102bcf6c3e9df32180a71b5ccfd1e0beb504fb5c86a18a53451c9ec76bc71415590377f59f5a003ec03136b6898185062446cdb8f005079a89 2) https://dist.apache.org/repos/dist/dev/netbeans/netbeans-maven-archetypes/netbeans-platform-app-archetype/netbeans-platform-app-arch etype-1.24/ sha512 5f5837b852aee6b1095505ec74a1d88d2734dd745e0b67da43a0f0177a1953e29334a9033120e28fe7401495f855f3f779d023e6041b2075e0e96173b2cc406c The source are respectivly located (repository, commit id, tag) 1) https://github.com/apache/netbeans-mavenutils-archetype-nbm-archetype With the commit id b7b46b8ade73e43c6b4ec9783dcd59f11b10a470 (tag nbm-archetype-1.19) 2) https://github.com/apache/netbeans-mavenutils-archetype-netbeans-platform-app-archetype with the commit id ff7b23476637cdfb3c61cff047e52005ace91530 (tag netbeans-platform-app-archetype-1.24) Archetypes are staged in the following maven repository https://repository.apache.org/content/repositories/orgapachenetbeans-1146/ 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 - 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 version 14.2
+1 (binding) - Checksum and signature are OK - Licenses are right, including NOTICE & LICENSE Thanks, Eric! On 31/7/24 14:39, Eric Barboni wrote: Hi folks I would like to artefacts for the Apache NetBeans utilities. In a grouped way synchronized on version 14.2 We have the following artefacts: -utilities-parent -nbm-maven-harness -nb-shared -nb-repository-plugin -nbm-maven-plugin Changes since last version are: - Format Specification versions in the same way than Netbeans by @YannLeCorse - dependencies update Source artefacts are on dist : https://dist.apache.org/repos/dist/dev/netbeans/netbeans-maven-utilities/14.2/ checksum : dd27415f7dbb715e98b1011dc5dc801fc81d8e84e666c1157d61c69a16e60559e16d939b99bfaa9fc54247faf2e7d766935a6e9e48dd1ab2559af1488ee1c994 In addition to that, artefacts build from https://github.com/apache/netbeans-mavenutils-nbm-maven-plugin tag utilities-parent-14.2 (commit id 48d854b8eec8f238036309d335ae130f6e48fdd9 ) are staged in https://repository.apache.org/content/repositories/orgapachenetbeans-1145/ Key file is here: https://www.apache.org/dist/netbeans/KEYS The vote is open for at least 72h. 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: Where is javax.help.HelpSet?
Hi, javax.help.HelpSet lives at [1], see also [2]. This is GPL licensed and as a consequence cannot be included in Apache NetBeans. HTH, Antonio [1] https://github.com/javaee/javahelp/blob/master/jhMaster/JavaHelp/src/new/javax/help/HelpSet.java [2] https://en.wikipedia.org/wiki/JavaHelp On 1/6/24 9:02, William Kida wrote: I’m a complete newbie in compiling Netbeans. Some imports can not be found, for example javax.help.HelpSet. It doesn’t appear to be in JDK 17 or even JDK 8. Thanks for any help Best regards, William Sent from my iPhone - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [VOTE] Release Apache NetBeans 22
Hi all, [+] yes / +1 [ ] no / -1 (please justify -1) [+] binding (member of PMC) My vote is based on [+] I have built and tested the source with OpenJDK Runtime Environment Corretto-17.0.5.8.1 (build 17.0.5+8-LTS) on Ubuntu 22.04.4 LTS (required) [+] I have tested the binary zip with on [ ] I have tested the installer(s) with on [ ] I have tested the Maven artefacts [ ] I have tested the VSCode extension Additional info (optional) - any specifics on what you've tested Thanks all!! Great release!! On 23/5/24 16:43, 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 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 22 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 source with on (required) [ ] I have tested the binary zip with on [ ] I have tested the installer(s) with on [ ] I have tested the Maven artefacts [ ] I have tested the VSCode extension Additional info (optional) - any specifics on what you've tested -- Thank you to all contributors for
Re: [VOTE] Release of Apache NetBeans utilities version 14.1
+1 (binding) Thanks, Eric! On 25/4/24 14:40, Eric Barboni wrote: Hi folks I would like to artefacts for the Apache NetBeans utilities. In a grouped way synchronized on version 14.1 We have the following artefacts: -utilities-parent -nbm-maven-harness -nb-shared -nb-repository-plugin -nbm-maven-plugin Changes since last version are: - Fix missing OutputTimestamp property to help reproducible builds by new contributor @charphi -updater warning fix - code reformat to default Apache NetBeans standard. -dependencies update -- make it possible to read nbm file compiled with jdk 22 - 23 Source artefacts are on dist https://dist.apache.org/repos/dist/dev/netbeans/netbeans-maven-utilities/14. 1/ checksum 8a878aef7513a0d3b45d281420a22610f3a00ea4e2d8cb9ca7d37cdf4a66c1805964a9f2045e 47f03831adf36c5343df814889dd8fbbf75e89ddd89541ed71b1 In addition to that, artefacts build from https://github.com/apache/netbeans-mavenutils-nbm-maven-plugin tag utilities-parent-14.1 (commit id 25653d3f7105cbf9e5009e5d9d24158d97a182cf) are staged in https://repository.apache.org/content/repositories/orgapachenetbeans-1140/ Key file is here: https://www.apache.org/dist/netbeans/KEYS The vote is open for at least 72h. Best Regards Eric - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [VOTE] Release Apache NetBeans 21
[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 64-Bit Server VM Corretto-11.0.17.8.1 on Ubuntu 22.04.3 LTS [X] I have tested the binary zip with OpenJDK 64-Bit Server VM Corretto-11.0.17.8.1 on Ubuntu 22.04.3 LTS [ ] I have tested the installer(s) with on [ ] I have tested the Maven artefacts [ ] I have tested the VSCode extension Additional info (optional) - any specifics on what you've tested Opened Maven and NetBeans Platform projects, everything runs smoothly. Thanks and congratulations, all! - 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 Windows launcher natives version 1-94a19f0
+1 (Binding) Checked signatures, checksums, licenses, NOTICE. Didn't build-run, though. On 8/1/24 19:00, Neil C Smith wrote: This is a vote on the Windows launcher native binaries. As the binary artefacts are consumed by the IDE build, we need to release them separately when they need updating. The main purpose of this version is to bring in the support for to_enable files as part of adding the ability to safely enable and disable module fragments https://github.com/apache/netbeans/pull/6743 Another purpose of this version is to have a first release of the launchers using the native binaries workflow introduced in https://github.com/apache/netbeans/pull/6869 This workflow works with the same principle as that used recently to release profiler and terminal native binaries (including artefact versioning). Voting artifacts are to be found here: https://dist.apache.org/repos/dist/dev/netbeans/native/netbeans-launchers/1-94a19f0/ Primary voting artefact : https://dist.apache.org/repos/dist/dev/netbeans/native/netbeans-launchers/1-94a19f0/launcher-external-sources-1-94a19f0.zip SHA512: 209115db03b4cbf472a026deaeeac7a6ffe319fb7a42f67719bebc5d743941b9ec7672a3e1f51390e779b948257aae58720cb9582a7fb46415ad6cf542265353 Zipped binary artefacts: https://dist.apache.org/repos/dist/dev/netbeans/native/netbeans-launchers/1-94a19f0/launcher-external-binaries-1-94a19f0.zip SHA512: e904b4ea540b5bcb8ab6ec7cc72a72810bb8a88ea6e210ce8f64bbaab3fa6d58891d2af272f1971863ae93f8b15e042ed243b7077a5f73a3ed1caeb05e77bc3d Once released the binaries will be consumed by the IDE. A draft PR, including dev build, using the staged artefacts is at https://github.com/apache/netbeans/pull/6933 The source and binary artefacts were created in GitHub actions run : https://github.com/apache/netbeans/actions/runs/7449143712 using the workflow at : https://github.com/apache/netbeans/actions/runs/7449143712/workflow The workflow extracts the necessary parts of the NetBeans repository into the source bundle, then passes the source bundle to separate runners to build the binaries. This ensures the source zip contains everything required to build the binaries. See the workflow file for how to replicate the build locally. 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. Many thanks everyone, 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
Drop libs.toml4j?
Hi all, It seems "libs.toml4j" is no longer maintained, and it's stuck at Antlr4 4.11.1 (superseeded by 4.13.1). As it is now it's not suitable for parsing Cargo.toml files in Rust. Shall we drop libs.toml4j? I've got a working Antlr4 Grammar that could be used in the "languages.toml" module for coloring etc. Or shall we keep it and add a specific parser just for Cargo.toml files? Any option fits me perfectly well. Cheers, Antonio - 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 20
[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 Runtime Environment Corretto-11.0.17.8.1 (build 11.0.17+8-LTS) on Linux 6.5.0 x86_64 (required) [X] I have tested the binary zip with OpenJDK Runtime Environment Corretto-11.0.17.8.1 (build 11.0.17+8-LTS) on Linux 6.5.0 x86_64 (required) [ ] I have tested the installer(s) with on [ ] I have tested the Maven artefacts [ ] I have tested the VSCode extension Additional info (optional) - any specifics on what you've tested Great job, everybody! Best release ever! On 28/11/23 10:46, Eric Barboni wrote: 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. - 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 version 14.0
+1 (Binding) Signatures look good. Ready to go. Apologies for the late response (busy days until end of year). Thanks and kind regards, Antonio P.S: We could copy the license header from .git-blame-ignore-revs into .gitignore in the future ;-) On 16/11/23 15:59, Eric Barboni wrote: Hi folks I would like to artefacts for the Apache NetBeans utilities. - 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: Language Server Protocol - rust-analyzer
D'oh! So we have people already integrating rust-analyzer, that's great news! Here's a volunteer! What shall I do? I'm currently working, as time permits, in rust support [1]. Currently adding support for Cargo workspaces. Cheers, Antonio [1] https://github.com/apache/netbeans/tree/master/rust On 11/11/23 17:26, arsi wrote: H*i,* Since yesterday I've been trying to run the rust-analyzer and I finally found the reason why it doesn't work.. In the *LSPBindings* class, *server.initialize* is called, but it should be followed by *server.initialized* and that is missing and that's why the rust-analyzer won't run. It would be ideal if we could find a volunteer to test it and commit it...😉 ArSi - 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 can I dynamically scale (enlarge) all GUI controls in my NetBeans Platform-based application to support accessibility?
Hi Dawid, Modern OSes have already useful tools for this testcase, I think. You can also try out setting the sun.java2d.uiScale in the netbeans.conf file (it works in my Linux box with integral scaling, i.e., 2, 3, etc.). It seems visualvm (NetBeans based) has this as a command line option [1]. If you decide to do it programmatically I'd suggest doing it in the look and feel, not in NetBeans itself. Cheers, Antonio [1] https://visualvm.github.io/docs/command-line-options.html On 2/11/23 7:39, Dawid Lokiec wrote: Hi, I'm working on a NetBeans Platform application and want to ensure accessibility by dynamically scaling up the GUI components for users with visual impairments. Is there a way to achieve this programmatically for all GUI controls? Primarily, I'm looking for a way to iterate through all the UI controls in the NetBeans Platform and somehow (are there setters for this?!) dynamically set the scaling in both the x and y dimensions based on the user's previous adjustment through the GUI. I would greatly appreciate it if someone could show me how to perform such an iteration and the API for setting the scaling. Thanks in advance. Dawid. - 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
New website issue tracker?
Hi all, I've just noticed that we've missed the "NetBeans history" web page. The source seems to be still there [1] but it isn't published at [2]. I'll try to take a look at it during the weekend, if possible. Question is: now that we have an Antora backed site, do we want to report issues somewhere? Cheers, Antonio [1] https://github.com/apache/netbeans-antora-site/blob/main/modules/ROOT/pages/about/history.adoc [2] https://netbeans.apache.org/front/main/about/history.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: [LAZY CONSENSUS] migrating our cms to antora
No objection from me. Great effort. Maybe we want to consider in the future: a) Using the Antora Maven Plugin [1]. b) Give the site a redesign. c) Reconsider having many different repositories. These make sense if things evolve at different speed and you want to version them, otherwise we may want to have everything in a single repo. Cheers, Antonio [1] https://gitlab.com/antora/antora-maven-plugin On 25/10/23 15:44, Eric Barboni wrote: Hi, As there it seems no objection. Works on fixing 404 (only on our "internal reference") and making better docs can continue later. I thinks it's almost the same content but publishable. PR ready for trying to publiush live is here: https://github.com/apache/netbeans-antora/pull/9 Best Regards Eric -Message d'origine- De : Antonio Envoyé : mardi 17 octobre 2023 19:21 À : dev@netbeans.apache.org Objet : Re: [LAZY CONSENSUS] migrating our cms to antora Hi, Some comments inline below: On 17/10/23 14:45, Eric Barboni wrote: Hi, Using a asf-staging branches to get it works via jenkins. Maybe Then maybe we want to close https://issues.apache.org/jira/browse/INFRA-25089 with a "works for me" or something. The CI build script at https://ci-builds.apache.org/job/Netbeans/job/netbeans-antora-website/configure has a "Credentials" drop box on each repository. We could add a new repository there with proper credentials but if the "asf-staging" branch works then I'd leave it as is. after a refresh a search bar should appears left to community. (lunr D'oh! So if I type "AbstractNode" I get a popup window with documents explaining it?. This is cool. Great work! (screenshot from https://netbeans-antora.staged.apache.org/front/main/index.html at https://ibb.co/c28CScj ) We may want to index the tutorials too (I've just seen wiki results). If the index for search gets big (as I presume will happen) we can always move to server-side search. extension). The UI is close to current website, if we wanna change we need a plan. But we are able to publish again via this setup so easier to see a future. Yep. Also the whole Antora structure/etc. should be documented somewhere (probably in a section under https://cwiki.apache.org/confluence/display/NETBEANS/NetBeans+Site). I can help with that as time permits, if we finally move onto Antora. Cheers, Antonio - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [LAZY CONSENSUS] migrating our cms to antora
Hi, Some comments inline below: On 17/10/23 14:45, Eric Barboni wrote: Hi, Using a asf-staging branches to get it works via jenkins. Maybe Then maybe we want to close https://issues.apache.org/jira/browse/INFRA-25089 with a "works for me" or something. The CI build script at https://ci-builds.apache.org/job/Netbeans/job/netbeans-antora-website/configure has a "Credentials" drop box on each repository. We could add a new repository there with proper credentials but if the "asf-staging" branch works then I'd leave it as is. after a refresh a search bar should appears left to community. (lunr D'oh! So if I type "AbstractNode" I get a popup window with documents explaining it?. This is cool. Great work! (screenshot from https://netbeans-antora.staged.apache.org/front/main/index.html at https://ibb.co/c28CScj ) We may want to index the tutorials too (I've just seen wiki results). If the index for search gets big (as I presume will happen) we can always move to server-side search. extension). The UI is close to current website, if we wanna change we need a plan. But we are able to publish again via this setup so easier to see a future. Yep. Also the whole Antora structure/etc. should be documented somewhere (probably in a section under https://cwiki.apache.org/confluence/display/NETBEANS/NetBeans+Site). I can help with that as time permits, if we finally move onto Antora. Cheers, Antonio - 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] migrating our cms to antora
Hi all, So the contents of [1] have been extracted into the "antora" branch [2] and are now available for preview at https://netbeans-antora.staged.apache.org I can't see a difference with the original. I was expecting some nicer tutorials, search boxes, three panel layout, etc., etc. Very much like the Antora documentation is generated (see, for instance, https://docs.antora.org/antora/latest/ ) Did we miss all the goodies Antora provides? That's a pity, isn't it? Any way we could generate the documentation similar to Antora documentation? Cheers, Antonio [1] https://ci-builds.apache.org/job/Netbeans/job/netbeans-antora-website/ [2] https://github.com/apache/netbeans-website/tree/antora On 16/10/23 19:03, Antonio wrote: It would be great if we could see the thing live before taking a decision. - 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] migrating our cms to antora
Hi, It would be great if we could see the thing live before taking a decision. I talked to ASF-Infra during the weekend, and they explained that you can set-up a branch in the current repository with the new content, and publish it in a staging website (see [1]). Question is, may I create an "antora" branch at https://github.com/apache/netbeans-website/ with the contents of the new site? AFAIU that would probably make the content available at https://netbeans-antora.apache.org, right? We can always delete the "antora" branch later on. Cheers, Antonio [1] https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#Git.asf.yamlfeatures-Stagingawebsitepreviewdomain On 16/10/23 18:22, Eric Barboni wrote: I would like to move from our gradle/jbake cms website to antora/asciidoc website. - 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 lib.profiler natives version 1-24aefa9
+1 (binding) Checked SHAsums and GPG signatures. Proper NOTICE/LICENSE. Sources include headers (*) Looks good to me. Thanks all! (*) /profiler/lib.profiler/native/README.txt doesn't have a license header, but that's ok. On 10/10/23 20:57, Matthias Bläsing wrote: This is a vote on the lib.profiler native binaries. As the binary artefacts are consumed by the IDE build, we need to release them separately when they need updating. The main purpose of this version is to allow us to ship Apple Silicon support for the profiler in NetBeans 20. Voting artifacts are to be found here: https://dist.apache.org/repos/dist/dev/netbeans/native/netbeans-profiler/1-r24aefa9/ Primary voting artefact : https://dist.apache.org/repos/dist/dev/netbeans/native/netbeans-profiler/1-r24aefa9/profiler-external-binaries-1-24aefa9.zip SHA512: fc8cd47aed268f6d98d3603e892632a8d0a14aaab68f62f05c807bf0a756ad9904ee4e5ad0f5a9e10168b71cf478cb57e229a49d002948b2239681df26df3392 Zipped binary artefacts: https://dist.apache.org/repos/dist/dev/netbeans/native/netbeans-profiler/1-r24aefa9/profiler-external-binaries-1-24aefa9.zip SHA512: bf4095f4df8781c9745c3ac60cfc1af3fcab06bfbb476fba86915056377c704ca70a8611c9b2e6c0963adbed260c7218b541787e3355b1548dcd5ddb7f730107 Once released the binaries will be consumed by the IDE. A draft PR, including dev build, using the staged artefacts is at https://github.com/apache/netbeans/pull/6502 (PR demonstrates principle, version is different). The source and binary artefacts were created in GitHub actions run https://github.com/apache/netbeans/actions/runs/6448227185 using the workflow at https://github.com/apache/netbeans/actions/runs/6448227185/workflow The workflow extracts the necessary parts of the NetBeans repository into the source bundle, then passes the source bundle to the various different OS runners to build the binaries. See the workflow file for how to build from source on each OS. 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. Many thanks everyone, Best wishes, 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] Release dlight.nativeexecution natives version 1-24aefa9
+1 (binding) Checked SHAsums and GPG signatures. Proper NOTICE/LICENSE. Sources include headers. Looks good to me. Thanks all! On 10/10/23 20:57, Matthias Bläsing wrote: This is a vote on the dlight.nativeexecution native binaries. As the binary artefacts are consumed by the IDE build, we need to release them separately when they need updating. The main purpose of this version is to allow us to ship Apple Silicon support for the terminal in NetBeans 20. Voting artifacts are to be found here: https://dist.apache.org/repos/dist/dev/netbeans/native/netbeans-nativeexecution/1-r24aefa9/ Primary voting artefact: https://dist.apache.org/repos/dist/dev/netbeans/native/netbeans-nativeexecution/1-r24aefa9/nativeexecution-external-sources-1-24aefa9.zip SHA512: 3617769041f2883ef522770d237ee30cbd2844b8b89eb466c3020247a151ac450615394705bae9291a8c452fb65199d2e765e45327776fc21af69ef20ddf5d44 Zipped binary artefacts: https://dist.apache.org/repos/dist/dev/netbeans/native/netbeans-nativeexecution/1-r24aefa9/nativeexecution-external-binaries-1-24aefa9.zip SHA512: 429b5ada5be9bf02b6aaa3da94880296c4052e036e805c64d114ac3bbe47f057a1b19251904ec1fefc3c21a24b8dbf553bbc9813fe717b9f4c94caf2c585e7e5 Once released the binaries will be consumed by the IDE. A draft PR, including dev build, using the staged artefacts for Apple Silicon only is at https://github.com/apache/netbeans/pull/6521 (PR demonstrates principle, version is different). The source and binary artefacts were created in GitHub actions run https://github.com/apache/netbeans/actions/runs/6448227183 using the workflow at https://github.com/apache/netbeans/actions/runs/6448227183/workflow The workflow extracts the necessary parts of the NetBeans repository into the source bundle, then passes the source bundle to the various different OS runners to build the binaries. See the workflow file for how to build from source on each OS (only macOS and Linux at present). 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. Many thanks everyone, Best wishes, 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] Release lib.profiler natives version 1-r2196e46
Ah, I see now. So we'll need votes for lib.profiler, dlight.nativeexecution, the launchers and some other native libraries and utilities (CND has two or three shared libraries/executables as well). So why not build, deliver and vote all of these at once? That'd require a single vote for all of them, right? Would that help? Cheers, Antonio P.S.: Since these binaries have a different release cycle than the rest of the code (I think we could compile them one/two three times a year, right?) we could create a new repository "netbeans-binaries" to build these (having the NetBeans repo as a submodule). There's no need to build these on each one of the PR submits, right? On 5/10/23 23:15, Neil C Smith wrote: On Thu, 5 Oct 2023, 21:00 Antonio, wrote: We currently depend on exechlp-1.2.zip [1] for dlight.nativeexecution, right? But nobody has voted _explicitly_ on that dependency. That's a pre-ASF binary as far as I know. However the ASF profiler binaries should really have been voted on and hosted elsewhere. We now build the new macos binaries for Apple Silicon, that we can download from dist.apache.org and then include them as we do with exechlp-1.2.zip. And no extra voting is required, right? They can't go on dist.a.o or Maven Central in the first place without a vote (Windows launcher is on Maven incidentally via vote). It is also distribution before release (even if only consumed by our sources), and has some other potential issues. Some are raised on that parent POM issue I linked. It has some parallels to this, although more concern for us because these are compiled code. Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [VOTE] Release lib.profiler natives version 1-r2196e46
Hi, I'm missing something here! I'd appreciate some explanations. We currently depend on exechlp-1.2.zip [1] for dlight.nativeexecution, right? But nobody has voted _explicitly_ on that dependency. We now build the new macos binaries for Apple Silicon, that we can download from dist.apache.org and then include them as we do with exechlp-1.2.zip. And no extra voting is required, right? Apple Silicon support is included in NB20 (downloading from dist.apache.org) as well as exechlp-1.2.zip (downloading from OSOUL) and everybody is happy, right? What's the problem? Whenever we release NB20 we'll vote for the new release as we always do (including those Apple Silicon binaries compiled from our own APLv2 sources). A single vote will do for everything. Why adding an extra vote? Thanks for the explanations, Antonio P.S.: Same thing for profiler binaries. [1] https://github.com/apache/netbeans/blob/master/ide/dlight.nativeexecution/external/binaries-list On 5/10/23 20:42, Neil C Smith wrote: Unfortunately that means we will likely now not have Apple Silicon support in NB20, unless someone else can pick it up, and also ironically we will end up continuing with the existing profiler binary that is *less* compliant with ASF release procedures. Our build process requires the distribution of binary native artefacts to people building from source. That source is not signed and is not voted on *at the point that those binaries are produced*. Neither are the binaries. It's a chicken and egg situation. Part of the release process is verifying the link between source bundle and binary. This does that. - 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 lib.profiler natives version 1-r2196e46
Hi, -1 (binding). AFAIK the source code is already hosted at [1] (with whichever modifications required to build properly), has been already voted upon previously, has been already reviewed, has proper NOTICE and license information and there's no reason to vote for it again. Whether we build "convenience binaries" for this source code for one or more platforms, and whether we deliver these binaries through "dist.apache.org" for internal consumption, or through OSOUL or through github or whatever is nothing we should be voting upon, I think. The less the votes, the better ;-) ! Kind regards, Antonio [1] https://github.com/apache/netbeans/tree/master/profiler/lib.profiler On 3/10/23 21:42, Matthias Bläsing wrote: -1 (binding) I'm sorry, but the binary artifact is missing LICENSE and NOTICE files. I would expect them to be located beside the BUILDINFO.txt file. - 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: website migration to antora
Hi, I did some experiments with Antora in the past (for the platform tutorials) and the results were very good. And one gets integrated search for free. I'm not sure Antora is a good solution for the whole web, though. It's very good for tutorials, but I'm not sure it's a good choice for front-pages, release summaries, blogs, etc. We'll need some other tool. Antora requires multiple repositories. It also requires node.js, so the other tool should be using that as well. The web could be divided in different parts (tutorials, blog and the rest, for instance). And that may fit nicely with multiple repositories. The idea is to avoid rendering thousands of pages when just a few ones change. Cheers, Antonio P.S.: We have many repositories, don't we? Worth using a github group? On 2/10/23 10:56, Eric Barboni wrote: Hi, I'm a bit annoyed by the current gradle build and would like to migrate to antora, means one repo for UI (css, and so one) and 1 to more repository for the content (keeping adoc). Maybe main site (download and community), documentation (tutorials, kb), wiki. Seen on other Apache site, httacess can be also handled so we should not loose fonctionnality. With po4a we could also have non english language linked to main english. Antora is able to check the xref beetween page and may a bit ease the work of hunting 404. Maybe we could let behind the old tutorial (6.5 . 8.1) 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: [DISCUSS] Status of tomlj
Hi, Well, the antlr4 grammar needed some hammer blows :-), but looks like we'll be able to parse that rust file after all... [1]. I tried to do a PR against tomlj, but it's too complicated for me to modify within my available time slots (I think it'll require changing the grammar, seems to be using tabs vs. spaces, NetBeans says all unit tests pass even when they fail, etc.). Cheers, Antonio [1] https://github.com/vieiro/toml-java https://github.com/vieiro/toml-java/tree/6298049f12271c4943f3ff2b52b0ccc902331cbb/src/main/antlr4/net/vieiro/toml/antlr4 https://github.com/vieiro/toml-java/blob/6298049f12271c4943f3ff2b52b0ccc902331cbb/src/test/java/net/vieiro/toml/TOMLParserTest.java#L188 On 25/9/23 21:23, Michael Bien wrote: b.2) To maintain the TOML/ANTLRv4 parser at [3]? This might be a good option, since grammar files are usually fairly compact, esp those for config file formats. You think the existing grammar of the grammar-v4 repo would be able to parse the rust file in question? - 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] Status of tomlj
Hi all, I've just found a bug in the tomlj library [1], which prevents the rust cluster to properly parse a well formed Cargo.toml document. So we need an alternate TOML parser for Rust. I've seen that the author of tomlj is requesting maintainers since 2022, with little success (I've also seen that Laszlo has been curious about mainteinance [2]). AFAIK the tomlj library is only used in Rust and ide/languages.toml. Also I found the grammar at [3] (__ASF__ APLv2 license) seems to work correctly in this case. Questions are: a) Any problem in replacing tomlj with an alternative? b) Do we prefer: b.1) To use an external library? b.2) To maintain the TOML/ANTLRv4 parser at [3]? b.3) Anyone wishing to maintain tomlj? Thanks, Antonio [1] https://github.com/tomlj/tomlj/issues/60 [2] https://github.com/tomlj/tomlj/issues/44 [3] https://github.com/antlr/grammars-v4/tree/master/toml - 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] Moving cnd forward
Some comments below On 18/9/23 22:56, Jan Lahoda wrote: On Mon, Sep 18, 2023 at 10:02 PM Antonio wrote: [...] I.e. the breakpoints from cnd.debugger.common2 would be used in "cpplite.debugger", which should resolve the MIME type clashes. AFAIK there used to be two separate debugger implementations, both based on cnd.debugger.common2, and we probably can have two now. At least until someone can merge the native image stuff from cpplite.debugger to cnd.debugger.gdb2. That's clever! Maybe worth exploring. Also, let's imagine that there're no cpplite-specific mime types (just cnd mime-types). Then could this merge of "cnd.debugger.gdb2 + cpplite.debugger" resolve behaviour depending on FileObject's project ownership (instead of MIME-type? Maybe worth exploring? [...] Regarding CProjectConfigurationProvider, that is the way (API) the location of compile_commands.json is passed from the project to the editor/LSP server. So, it does not make much sense to push that into the project. Some API like this should be near cnd.lsp, unless it already exists. An implementation of the API should be in the project, replacing the current: https://github.com/apache/netbeans/blob/72a8dada6db920234b961b8af5631f44bbe4d73d/cpplite/cpplite.project/src/org/netbeans/modules/cpplite/project/CPPLiteCProjectConfigurationProvider.java#L32 Yes, this CPPLiteCProjectconfigurationProvider could be an SPI in cnd.lsp for projects to implement & include in the project Lookup. That can be done for Make based projects as well, I think. UnconfiguredHint has two parts: a) a warning the user that there's no clangd/ccls configured - unless cnd already has something like that, it probably would be reasonable to have it; and b) that the compile_commands.json is not configured in the project, and this is cpplite specific. IIRC the rust cluster displays a NotificationDisplayer + link to Options when misconfigured. That can be reused for a) above. this "native image debugging" works. Is anyone using this "native image debugging" functionality? How is it used? It would be good to know how to do this. I imagine you specify a graalvm generated executable and a set of C source code directories in compile_commands.json and then debug it, right? Cheers, Antonio - 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] Moving cnd forward
Hi, Wow, that seems a lot of work to do _on cpplite_ in order to have cnd integrated. Also it seems to me there're lots of unknowns in the road! The blockers I see are: -A) If the cpplite.debugger is to be kept "for native image debugging" then cpplite.editor MIME registration should also be kept, because NetBeans breakpoints are mime-type dependent (see [1], for instance). -B) And if cpplite.editor MIME registration is to be kept then CND cannot register mime types, as NetBeans is unable to assign mime types "text/x-c" (CND) and "text/X-c" (cpplite, note upper case X) simultaneously for files with the same extension (*.c, *.cxx, etc.). So, to summarize: the blocker is that a file with extension ".c" cannot be registered with different mime-types (with different breakpoints), which is required if wishing to have two different debuggers with different breakpoints. To solve the situation the only think I can think of is: 1.- keep a single debugger which, due to code length, should be the pair cnd.debugger.common2/cnd.debugger.gdb2 (cpplite.debugger uses these in binary form, after all). 2.- regarding cpplite.project, I think this should be transformed in some sort of "cnd.cpplite.project" or similar (some sort of CND free-form project), in the cnd cluster, integrating the CProjectConfigurationProvider and UnconfiguredHint currently in cpp.editor (these are project-specific APIs, right?). 3.- with a single debugger and a cnd.cpplite.project similar to cpplite.project, then cpplite.editor is superfluous and could be removed, I think. Note that ide/nativeimage.api has a test dependency with cpplite/cpplite.editor [2]! that should clarified (what's this used for?, how does a module in the ide cluster depend on the cpplite cluster?). I think I could give a "cnd.cpplite.project" a try, incorporating stuff from cpplite.project and cpplite.editor, but then I'll need to know how this "native image debugging" works. Is anyone using this "native image debugging" functionality? How is it used? If the experiment fails then cnd and cpplite could not coexist, and we should devise another alternative (CND release without cpplite, or letting the user choose betwween cpplite/cnd at runtime, disabling one or the other). Cheers, Antonio P.S.: Some clarifications about CND: - cnd.lsp, does not "not compute the compile_commands.json itself", as stated. This is delegated to cnd's make based projects: only cnd make based projects generate a compile_commands.json automatically. - cnd.lsp is agnostic about compile_commands.json: if the file is there the LSP server will detect and use it. Otherwise the LSP server will have no compile_commands.json (LSP servers usually provide some hints even if the file is missing). - cnd.lsp currently starts clangd, but could also launch ccls if required (ccls expects offsets based in UTF-16 encoding, as the LSP specification mandates, which is not the case in NetBeans, where offsets are UTF-8 based, AFAIK). [1] https://github.com/apache/netbeans/blob/b5a8baff7408fb4f07633a38d47c3279453f6fc6/cpplite/cpplite.debugger/src/org/netbeans/modules/cpplite/debugger/breakpoints/CPPLiteBreakpointActionProvider.java#L43 [2] https://github.com/apache/netbeans/blob/b5a8baff7408fb4f07633a38d47c3279453f6fc6/ide/nativeimage.api/nbproject/project.xml#L97 On 16/9/23 15:31, Jan Lahoda wrote: Hi Antonio, Great to see progress on CND! First, the mime types in cpplite were intended to automatically "disable" the cpplite functionality when CND is installed. So, these are not intended to be used at the same time. OTOH, it is true cpplite is used a little bit more than anticipated. So, let us analyze the parts of cpplite: - cpplite.editor does three (or four) things: -- registers the MIME types, and creates DataObjects for the C/C++ files. It should be possible to delete these, only keeping the CND version of this functionality, assuming the rest of the code is adjusted to this, see below. -- starts the C/C++ LSP server + provides configuration for it. This should be deleted, and the version from CND should be used. But, IMO, the CND version should be extended to support "ccls" (as the cpplite version has been extended to support both ccls and clangd, unless there's a compelling reason to not support ccls). Also requires the API from the next point. -- provides a (friend) API using which the projects can provide the compile_commands.json for the server: https://github.com/apache/netbeans/blob/master/cpplite/cpplite.editor/src/org/netbeans/modules/cpplite/editor/spi/CProjectConfigurationProvider.java I suspect a similar API should be adopted by CND (and, maybe, the cnd.lsp module should not compute the compile_commands.json itself - the projects should do it, and cnd.lsp should only use the provided data).
[DISCUSS] Moving cnd forward
Hi all,
So it seems people is interested in the CND branch for C/C++
development, and we now have three PRs from external contributors [1].
STATUS:
As you may know the CND branch has been pruned from the original Oracle
donation (due to license restrictions and code provenance issues), and
it's clean from a license point of view. It currently collides with the
cpplite cluster (see [2] for details).
When compiled without "cpplite" the "cnd" branch is able to open old
"C/C++" projects, run and debug them, add syntax highliting, etc. cnd is
also able to automatically generate a "compile_commands.json" from
"C/C++" make based projects (with compiler settings and external library
dependencies, including "pkg-config" dependencies), and it starts and
connects to the "clangd" LSP server for extra features.
Since the "cpplite" suite is used elsewhere (some people in the OpenJDK
Team use it for debugging GraalVM stuff, I think) somebody asked to keep
"cpplite" around.
OPTIONS:
So we have now two opposite forces: the "cpplite" users and the "cnd"
contributors wanting to move things forward.
To satisfy both forces I think we could:
A) Allow the user to switch between "cpplite" or "cnd" at runtime (I
don't know how to do this).
B) Create a "cnd-only NetBeans edition" without "cpplite". Release
schedule for cnd could go with a different frequency from the official
NetBeans release.
C) Make a separate repository for "cnd", transforming it into a plugin,
possibly under the Apache NetBeans umbrella, so people can contribute to it.
Depending on the solution above, and to ease development we could:
D) Merge "cnd" into "master", disabling the "cnd" branch for release (as
we currently do with the "rust" suite).
Note also that cnd has some characteristics of its own (see [3]), that
should also be taken into account before a decission is made.
So, what say? Any opinion ideas on how to evolve cnd? Any other
alternatives you may think of?
Cheers,
Antonio
[1]
https://github.com/apache/netbeans/pull/6439
https://github.com/apache/netbeans/pull/6440
https://github.com/apache/netbeans/pull/6441
[2]
Both "cpplite" and "cnd" want to assign different mime types ("text/X-c"
and "text/c-c" to files with extensions ".c" (".cpp", ".CC", etc.).
NetBeans has difficulties handling different mime types for the same
file extension.
I tried using a custom MimeResolver (that tries to guess if a file with
".c" extension is owned by cpplite or cnd) without success.
So currently "cpplite" and "cnd" are exclusive: only one of them may be
active for handling files with ".c" (".cc", ".cxx", etc.) extensions.
[3]
Some considerations on the cnd branch:
3.1- Many modules specify JDK8 as the base jdk version.
3.2- AFAIK cnd has not been tested with the most recent GitHub actions
testing stuff.
3.3- cnd still has many redudant code (legacy from the Sun/Oracle Studio
days?) that should be pruned and updated. There're many
"System.getProperty" flags that affect logging and behaviour, this
should be cleaned up in the future, I think.
3.4- IMHO there's little interest in the NetBeans committers about cnd
(users may still want to use cnd, though).
-
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: x11 resource claim of graph applet in performance toolbar
Hi, Please specify steps to reproduce this. "Large heap" is subjective. "When looking at xrestop you can see 'it' growing every second" is also ambiguous: what's exactly growing every second? I installed xrestop and switched to the Metal Look and Feel, and the xrestop line remains unchanged for NetBeans even if I resize the window. Cheers, Antonio On 5/9/23 19:54, Simon IJskes - QCG wrote: I cant be absolute, but the majority of the graphic contexts is returned with a garbage collection. The problem is, with a large heap, the X11 server resources are exhausted (so it seems) before a garbage collection occurs automatically. Also the Xserver memory consumption can easily go over 4Gb. Other L&F do not have this problem. It is only reproducable with Metal L&F. - 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 19
-- Answer form [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 11.0.17 2022-10-18 LTS on Ubuntu 22.04.3 LTS (jammy) (required) [ ] I have tested the binary zip with on [ ] I have tested the installer(s) with on [ ] I have tested the Maven artefacts [ ] I have tested the VSCode extension Thanks everybody!! -- - 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] Apache NetBeans 19 release candidate 5 available for testing
:set nohls solved the situation :-D. Apologies for the noise. Cheers, Antonio On 24/8/23 9:21, Antonio wrote: Hi all, I'm seeing weird "green" artifacts in RC5 when jVi is activated [1]. Any ideas anyone on what could be causing this? Thanks, Antonio [1] https://ibb.co/HqmLK6C On 15/8/23 20:17, Neil C Smith wrote: Please help with testing, and file issues in GitHub as necessary - https://github.com/apache/netbeans/issues - 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] Apache NetBeans 19 release candidate 5 available for testing
Hi all, I'm seeing weird "green" artifacts in RC5 when jVi is activated [1]. Any ideas anyone on what could be causing this? Thanks, Antonio [1] https://ibb.co/HqmLK6C On 15/8/23 20:17, Neil C Smith wrote: Please help with testing, and file issues in GitHub as necessary - https://github.com/apache/netbeans/issues - 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: Contrib Repo
Correction: Since the code is GPLv2+CPE or CDDL (at our discretion, you're expected to choose one): - It cannot be integrated in an Apache Repository (i.e. the source cannot be merged). - CDDL binaries can indeed be used in Apache Projects. In fact we do use many CDDL binaries in NetBeans. Apologies for the typo, Antonio On 12/6/23 11:56, Antonio wrote: Since the code is GPLv2+CPE or CDDL, it cannot be used in Apache projects (i.e., it cannot be integrated in an Apache repository), but can live as a NetBeans plugin(s) elsewhere. - 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: Contrib Repo
Hi, Of course you may fork that source code either totally or partially and modify and enhance it as you see fit. That's what open source is all about. You may then create a NetBeans plugin and request for it to be published in the NetBeans portal, for instance. Things you should keep in mind: 1- You must respect the source code license (i.e., you cannot change the GPLv2+CPE/CDDL license to Apache License, for instance, unless the original authors, whoever they are, give you permission to do so). 2- You must keep the copyright notices (you should add yours to your modifications too). Since the code is GPLv2+CPE or CDDL, it cannot be used in Apache projects (i.e., it cannot be integrated in an Apache repository), but can live as a NetBeans plugin(s) elsewhere. HTH, Antonio On 5/6/23 21:29, Chris wrote: Do I need to create a new plugin for this and this will by my "fork" of this or how should we do this? Should all of them treated as 3rd party plugins? - 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 18
-- Answer form [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 64-Bit Server VM Corretto-11.0.17.8.1 (build 11.0.17+8-LTS, mixed mode) on Ubuntu 22.04.2 LTS (required) [X] I have tested the binary zip with OpenJDK 64-Bit Server VM Corretto-11.0.17.8.1 (build 11.0.17+8-LTS, mixed mode) on Ubuntu 22.04.2 LTS [ ] I have tested the installer(s) with on [ ] I have tested the Maven artefacts [ ] I have tested the VSCode extension Great work, everybody!! -- - 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] Release Apache NetBeans 18: ConcurrentModificationException from javascript scanning
There's a typo here, I think: When you say "I should have done it in RC" you should be probably saying "_we_ should have done it in RC". Cheers, Antonio On 24/5/23 18:33, Matthias Bläsing wrote: This is in the voting instructions: [...] As well as checking any artefact functions correctly [...] Well, that was what I have been doing and yes I should have done it in RC. - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Netbeans + ssh -x
Hi Peter, Thanks for clarifying! These problems are usually X11 or JDK related, NetBeans uses Swing extensively, and rendering is performed by the JDK and X11, so I'd guess that it's JDK/X11 part which is having rendering problems. In order to better determine where the problem is we'll need more information. - NetBeans: are there any exceptions logged in the NetBeans log file? - JDK: are you having a core dump of the JDK (an hsperf file logged somewhere? - X11 Client: any logs you could provide? Also, what's the problem you're having? The whole X-Client crashes down or is it just NetBeans? You may want to try out different JDK 2D rendering settings in your remote NetBeans (see [1]) by adding them to the netbeans.conf file (-J-D...). These may differ among different JDK vendors. I'd try disabling OpenGL Cheers, Antonio [1] https://docs.oracle.com/javase/8/docs/technotes/guides/2d/flags.html Things I'd try: -J-Dsun.java2d.opengl=true|false -J-Dsun.java2d.pmoffscreen=true|false Also try to add an environment variable J2D_PIXMAPS=shared|server. On 5/5/23 8:53, Peter Kovacs wrote: Sorry for the confusion. The crash on Windows can be reproduced relatively often when pressing the toolbar button for git push. It is far less likely, when Netbeans - menus are used. - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Netbeans + ssh -x
Hi Peter, I'm afraid this email of yours has too little information and is not understandable. The "ssh -x" part in the subject suggests you're doing some sort of X11 forwarding for this remote server, but that would require a capital X in the flag (ssh -X) and not the lowered case one that you're posting. The body of your message suggests you're having a problem with a x-server on Windows, that is not reproducible on linux? and you're blaming NetBeans for that. Also there's no stack trace or any other hint of the problem you're having that explains why you think NetBeans is failing in your setup. I suggest you redacting your email properly, adding more information, at the risk of being ignored in this mailing list. HTH, Antonio On 4/5/23 21:01, Peter Kovacs wrote: Hello all, Following situation: for a complex web service I have moved a development environment (Netbeans + PHP module) on server. Devs on Windows experience now crashes when using buttons on top for push, pull. Menu seems less affected. Does anyone has experience with this sett up? Is there a difference between buttons in main windows or if I use the git menu? How do i find the implementation in the code? Any idea how to debug this? All the best Peter - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] disable remote index extraction by default [NB18]
+1 to all these. The problem I have is that the Lucene indexer seems to be very CPU intensive, and my laptop starts levitating with all fans at full speed. This is a problem when working on open spaces, because the laptop becomes a sort of drone, but without remote control. Luckily the battery dies soon and the laptop ends up crashing quickly from a not very high altitude :-). Now, seriously, it would be great if the indexing could be performed with a single low priority thread, gradually, even during several days, if required. Cheers, Antonio On 18/4/23 7:48, Jan Lahoda wrote: - explicitly ask before downloading (possibly allowing the user to select auto-download) - 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) - given thathttps://github.com/apache/netbeans/pull/4999 produces a smaller index, we could have a download location (server) at least for - 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] maven remote repo indexer improvements
Hi, This happens in some Linux distros that have a small /tmp directory (an older Debian default partitioning did this, for instance). I usually add a "-J-Djava.io.tmpdir=$HOME/tmp/NB" to the list of options in the [NETBEANS_INSTALL_DIRECTORY]/etc/netbeans.conf#netbeans_default_options line. HTH, Antonio On 18/4/23 21:46, Jakub Herkel wrote: 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. - 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: [RESULT][VOTE] Releasing of nbm-archetype 1.18 netbeans-platform-app-archetype 1.23
D'oh, I missed this vote. If possible let's add late a +1 vote there. On 17/4/23 11:15, Eric Barboni wrote: We have 3+1 binding votes - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
Hi, So are these "hundreds of people" Oracle customers, Toni customers, both Oracle and Toni customers or any other kind of users, say open source projects? Thanks, Antonio On 8/4/23 14:04, Jaroslav Tulach wrote: 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. - 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)
+1 On 3/4/23 11:38, Neil C Smith wrote: Thanks, Neil Thank you, Neil, for a reasonable proposal. It's great to try to support the oldest JDKs possible, but that doesn't mean we have to live stuck in the past forever. The proposal to use NB18 release branch for backports makes sense to me, too, so people that require JDK8 compatibility can contribute there. Cheers, Antonio - 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: maven indexing tweaks
Hi, These are impressive savings! Out of curiosity, we don't build the index incrementally using Maven's IndexReader, do we? That's why we download the whole index, right? Thanks, Antonio [1] https://maven.apache.org/maven-indexer/indexer-reader/apidocs/org/apache/maven/index/reader/IndexReader.html On 17/3/23 11:06, Michael Bien wrote: Hello everyone, I experimented a bit with the maven index extraction process and got some pretty good results (I think). There might be a way to filter the index during extraction without noteworthy overhead, which allows the following: - "sliding window" time filters, e.g drop all documents older than 2 years (aka: who uses old libraries?) - we can drop fields we don't need from the index. Esp interesting for fields which don't compress well (looking at you, sha1 hash) some results for the time cutoff filter: full: 5.6 GB 2y: 2.6 GB 1y: 1.4 GB - 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] Security and lunching programs from the IDE
Hi all, For the Rust support we want to rely on Rust's "cargo" command to perform different tasks (adding dependencies, building and running projects, etc.). This is very much the same we do with other external tools we may use, such as "maven", or "npm" or "gradle" (we use our embedded "ant" though, AFAIK). The question is, shall the IDE ask the user for permission before using any of these external commands? Or is it ok to find them in the PATH, for instance, and start using them directly? Opinions? Thanks, Antonio P.S.: I know we're warning the user before opening a Gradle "build.gradle" script, for instance (since we have to run the script to evaluate it, whereas Maven scripts are declarative). Visual Studio Code also asks for user permission before opening many projects. - 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 Swag Proposals - voting / next steps
+1 to all of these. My old NetBeans t-Shirts are falling apart! Now, when will these be available? Thanks Antonio On 11/3/23 16:43, Pyro MX wrote: Good (morning|day|afternoon|night) NetBeans devs, With the much appreciated help of Emmanuel Hugonnet, Mark Thomas and Geertjan Wielenga, I am ready to present to you the swag proposals we've been working on in the past few months. * T-shirt designs: https://github.com/njuneau/netbeans-swag/blob/main/proposals/previews.svg * Long-sleeved designs: https://github.com/njuneau/netbeans-swag/blob/main/proposals/previews-with-side-print.svg If you have difficulty seeing them in the browser, the required software and fonts are listed here if you want to see them on your computer: https://github.com/njuneau/netbeans-swag/blob/main/README.rst#prerequisites At this point, the things left to do are: * Vote whether or not the designs pass the developers' approval * Should the designs be approved, initiate the process with ComDev to have the store items up on RedBubble. I am not quite sure how the vote should be handled (would it be like a release vote?), but in any case, let's use this thread to discuss the next steps! I sincerely hope you like the designs, it has certainly been fun making them! - 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: heads up: Rust not properly squashed to master
Hi, I think squashing at home is the way to go. Looking at the archives, Matthias asked in may 2020 [1] to disable github's squash-and-merge button completely (because authorship was mangled with). That was a great piece of advice, I think. Cheers, Antonio [1] https://lists.apache.org/thread/f7vqowtobdfj1t53sfvsdpzx2w5d48j5 On 6/3/23 20:44, Michael Bien wrote: On 06.03.23 20:25, Michael Bien wrote: - rebase to latest master and force push to PR, wait for green CI -> merge gh has a compare button which also handles force pushes. The diff should be empty post squash - that is easy to verify. small correction: the last rebase-to-latest-master should be skipped if it is post review unless there is a good reason for that (e.g conflicts/very old PR). Since this will actually produce a huge diff when the compare button on the force push is pressed and make it very hard to see what happened in that force push (it should be empty if it was just a squash/commit cleanup for easy verification). -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: heads up: Rust not properly squashed to master
Well, my sincere apologies for all this trouble! Next time I'll squash at home first! Cheers, Antonio On 6/3/23 20:33, Matthias Bläsing wrote: I prefer sensibly squashed commits, because this makes it easier to see what was done, is easier to revert if necessary and history can be easier read. None of these goals is accomplished by reverting and reapplying squashed. So lets keep it as is, be happy with the rust additions and try to do better in the future. - 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
heads up: Rust not properly squashed to master
Hi all, It seems the Rust branch was not cleanly squashed and merged to master (I used the Github's "Squash and Merge" button), so we ended up with different commits in master. Do we revert those commits in master? Thanks, Antonio - 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, Lexer Issues
Hi László,
Some comments inlined below.
On 6/3/23 17:23, László Kishalmi wrote:
Well, this one is mostly for Antonio.
At the beginning of the Rust, anyone thread you were hitting some assertion
errors in LexerInput.
I have not seen the stacktrace, but I'd guess that's due to the original
error handling in ANTLR.
Yep, at the beginning I hitted some AssertionErrors in LexerInput.
The problem appeared when I typed a quoted string when another posterior
token string was present in the file. The Lexer (can't tell if Antlr or
NetBeans) was getting confused because it was hitting the EOF token
(looking for a second matching ") and it couldn't find one.
I solved the problem in the Lexer grammar by allowing the special token
EOF to end STRING_LITERAL [1] RAW_STRING_LITERAL [2] and
BYTE_STRING_LITERAL [3] (note the ('"' | EOF) construct there). After
that everything worked normally.
I think Antlr4 was getting confused because it couldn't detect the end
of the token, and this unexpected EOF was causing trouble (and
generating those AssertionErrors). Maybe we can detect these situations
in Antlr4Bridge, but I can't really tell.
Is that true? Is that the reason why:
https://github.com/apache/netbeans/blob/5934827e80797ec9b93ff28635ce7fca12627a70/rust/rust.grammar/src/org/netbeans/modules/rust/grammar/RustLanguageLexer.java#L80
has been put in code?
Not really, `lexer.removeErrorListeners()` (and
`parser.removeErrorListeners()`) seems to be the standard practice in
Antlr4: Antlr4 adds an error listener that logs errors to System.out,
and I wanted to get rid of that for NetBeans.
I'm asking because I'm hitting the assertion in my recent HCL Lexer and
suspect the default ANTLR error handling as a source. So this just would
reassure me, and also can replace the default error handler in the
AbstractAntlrLexerBridge.
See [4] (the Rust AST building parser) and [5] (a custom Antlr4
ErrorStrategy) for a more complete example of lexing/parsing and error
handling.
The RustANTLRErrorStrategy [5] is throwing RecognitionExceptions on
reportMissingToken, and this stops the parser from asking new tokens (as
far as I can tell) and better handles situations when the user is typing
something and parsing cannot continue.
BTW, Thanks for moving the Rust effort!
Thank YOU for the Antlr4 Bridge, Rust support couldn't happen otherwise!
Kind regards,
Antonio
[1]
https://github.com/apache/netbeans/blob/master/rust/rust.grammar/src/org/netbeans/modules/rust/grammar/antlr4/g4/RustLexer.g4#L208
[2]
https://github.com/apache/netbeans/blob/master/rust/rust.grammar/src/org/netbeans/modules/rust/grammar/antlr4/g4/RustLexer.g4#L212
[3]
https://github.com/apache/netbeans/blob/master/rust/rust.grammar/src/org/netbeans/modules/rust/grammar/antlr4/g4/RustLexer.g4#L216
[4]
https://github.com/apache/netbeans/blob/master/rust/rust.grammar/src/org/netbeans/modules/rust/grammar/ast/RustAST.java#L151
[5]
https://github.com/apache/netbeans/blob/master/rust/rust.grammar/src/org/netbeans/modules/rust/grammar/ast/RustAST.java#L112
-
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: prs
Some comments inline
On 5/3/23 8:39, name name2 wrote:
Hello
Questions from PR: #5598
I need test guidance and consult the tutorials for PRs.
Google points you to
https://netbeans.apache.org/tutorials/nbm-test.html, which is not
reviewed but still mostly useful.
To test a module in NetBeans you choose "Run / Test Project" in the main
menu or "ant test" from the command line.
You may also want to run other different tests:
ant rat : Checks for files that do not comply with ASF licensing.
ant verify-libs-and-licenses: Similar to above, for license content.
ant commit-validation: Tests IDE to validate before commit.
ant tryme: To run the resulting IDE and see everything works as expected.
Also i need approve is this changes acceptable:
The rest of your email is not understandable. It looks like a copy of
the changes you want to do in your PR without any explanation. You only
need to discuss in the mailing lists those changes that are an API/SPI
change (this is, those that may affect the people using the API).
It seems you're trying to change many things at once: tests, UI forms,
APIs, etc.
I'd suggest you focus on **modifying tests only in your PR** and
temporarily remove the rest of changes (API/SPI changes, desynchronized
Java-form files, etc.), make sure that those tests work properly.
When tests (and only tests) work properly for you, ask for review of
your PR. Once the PR is approved, tackle the rest of changes (APIs,
forms, etc.) in a different PR.
The objective is to make sure that the tests you are modifying work
properly, so that we do not accidentally end up with a red master
situation [1] as in february.
Cheers,
Antonio
[1]
https://lists.apache.org/thread/lkrmz7ko104qrl44g8tfr6s7lqvvghr8
WsitProjectOpenedHook:
WsitPojectOpenedHook -> WsitProjectOpenedHook
ErrorUtils:
public static void processError(BmcResponse reqest, String errorMessage) {
→ local variable name
public static void processError(BmcResponse request, String errorMessage) {
CommandRestTest:
removed unused import
enterprise/web.core.syntax/src/org/netbeans/modules/web/core/syntax/resources/layer.xml
->
->
enterprise/web.core.syntax/src/org/netbeans/modules/web/core/syntax/resources/layer.xml
ide/bugzilla/src/org/netbeans/modules/bugzilla/query/QueryParameter.java
*PV_FIELD_REP_PLARFORM*
->
*PV_FIELD_REP_PLATFORM*
ide/csl.api/apichanges.xml
->
DocumentationUrl description
Extending code completion hadler to provide a way client may
specify external documentation URL.
->
Extending code completion handler to provide a way client may
specify external documentation URL.
ide/libs.graalsdk/test/unit/src/org/netbeans/libs/graalsdk/ScriptingTutorial.java
tetsAccessJSONObjectProperties
→ (tets)
testAccessJSONObjectProperties
ide/properties/test/qa-functional/src/lib/PropertiesEditorTestCase.java
openExistedPropetiesFileInClassicEditor
→ (Propeties)
openExistedPropertiesFileInClassicEditor
ide/team.commons/src/org/netbeans/modules/team/spi/TeamAccessor.java
*PROP_PROJETCS_CHANGED*
->
*PROP_PROJECTS_CHANGED*
java/form/src/org/netbeans/modules/form/project/ClassPathUtils.java
public static void releaseFormClassLoader(FileObject fileInPoject) {
->(Poject)
public static void releaseFormClassLoader(FileObject fileInProject) {
java/maven/src/org/netbeans/modules/maven/NbMavenProjectImpl.java
void startHardReferencingMavenPoject() {
->(Poject)
void startHardReferencingMavenProject() {
void stopHardReferencingMavenPoject() {
->(Poject)
void stopHardReferencingMavenProject() {
java/refactoring.java/test/qa-functional/src/org/netbeans/modules/test/refactoring/operators/IntroduceParameterOperator.java
public JCheckBoxOperator getGenerateJvadoc() {
->(Jvadoc)
public JCheckBoxOperator getGenerateJavadoc() {
nbbuild/antsrc/org/netbeans/nbbuild/FixTestDependencies.java
boolean readCodeNameBases(Set compileCNB,
Set testsCNB,
Properties projectPropertis,
String property,
Set allCnbs,
Set entries) {
→ (projectPropertis)
boolean readCodeNameBases(Set compileCNB,
Set testsCNB,
Properties projectProperties,
String property,
Set allCnbs,
Set entries) {
nbbuild/installer/mac/newbuild/build.xml
->
->
nbbuild/installer/test/test/org/netbeans/test/installer/Utils.java
public static void stepChooseComponet( String name, TestData data )
->(Componet)
public static void stepChooseComponent(String name, TestData data )
php/php.dbgp/src/org/netbeans/modules/php/dbgp/models/nodes/ContextNode.java
public int getVaraibleSize() {
->(Varaible)
public int getVariableSize() {
platform/openide.util/test/unit/src/org/openide/xml/XMLUtilTest.java
public void
findSubElements_returnsEmptyList_whenNodeWithCommentAndBlankTextChidrenOnly()
{
->(Chidren)
public void
findSubElements_returnsEmptyList_whenNodeWithCommentAndBlankTextChildrenOnly()
{
platform/sendop
Re: Rust, anyone?
Hi,
In order for org.netbeans.modules.ide.ergonomics.DynamicVerifyTest to
pass the commit validation test, one has to add ProjectFactories in the
test itself, as in [1].
This works fine if the ProjectFactory is included in the cluster
configuration ("full" for instance) but makes the test fail if the
ProjectFactory is not included in the cluster ("release" for instance).
I think we should make DynamicVerifyTest know which ProjectFactory's to
test depending on the cluster configuration. I give it a run during this
weekend.
Also we should check that -Dcluster.config=release is still working
properly to see if any other tests depend on the cluster configuration.
Cheers,
Antonio
[1]
https://github.com/apache/netbeans/blob/a74f83d37ad54370274c56f7435bc32601188a42/ergonomics/ide.ergonomics/test/unit/src/org/netbeans/modules/ide/ergonomics/DynamicVerifyTest.java#L148
On 26/2/23 22:15, Michael Bien wrote:
Hi Antonio,
this draft tests switching CI from release to the full cluster config.
https://github.com/apache/netbeans/pull/5568
the properties file does need some cleanup IMO and we should make sure
that the cluster order isn't significantly different from whatever ends
up running during CI and the release config.
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: Rust, anyone?
Hi,
Wow, it's full of clusters [1]!
Taking a look at cluster.properties I noticed these entries for the
update centers...
nb.cluster.stableuc.depends=${clusters.config.full.list}
nb.cluster.betauc.depends=${clusters.config.full.list}
nb.cluster.experimental.depends=${clusters.config.full.list}
If we added "rust" to "clusters.config.full.list" will it end up in the
stable update center? Maybe we don't want that yet, right?
Maybe we want a "cluster.config.beta.list" instead of
"cluster.config.full.list"?
Cheers,
Antonio
[1]
clusters.config.basic.list
clusters.config.betauc.list
clusters.config.bloated.list
clusters.config.cndext.list
clusters.config.cnd.list
clusters.config.cpplite.list
clusters.config.dlight.list
clusters.config.enterprise.list
clusters.config.experimental.list
clusters.config.full.list
clusters.config.groovy.list
clusters.config.identity.list
clusters.config.javacard.list
clusters.config.java.list
clusters.config.jdev.list
clusters.config.minimal.list
clusters.config.mobility.list
clusters.config.odcs.list
clusters.config.php.list
clusters.config.platform.list
clusters.config.python.list
clusters.config.release.list
clusters.config.remote.list
clusters.config.rust.list
clusters.config.stableuc.list
clusters.config.standard.list
On 26/2/23 20:44, Michael Bien wrote:
btw, Matthias' proposal to use the full config is exactly the same as my
proposal since full would be release + rust which is what I mean 😄
the full property is just built differently and has different cluster
ordering.
-
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?
By the way, don't know how to set this up in cluster.properties, build fails with: netbeans/nbbuild/build.xml:677: Target "all-rust.cargo" does not exist in the project "main". It is used from target "nbmerge-build-one-cluster". Since I removed "rust" from clusters.config.full.list at https://github.com/apache/netbeans/pull/5567/commits/dbab8ca220fb42a3c7282815e4cfb99d28b77759 On 26/2/23 12:58, Antonio wrote: Hi, So I skipped 1.2 and did a PR against master. Let me know if you prefer a PR against a "rust" branch, though. Kind regards, Antonio [1] https://github.com/apache/netbeans/pull/5567 - 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?
Hi, So I skipped 1.2 and did a PR against master. Let me know if you prefer a PR against a "rust" branch, though. Kind regards, Antonio [1] https://github.com/apache/netbeans/pull/5567 On 24/2/23 18:21, Michael Bien wrote: On 24.02.23 18:21, Neil C Smith wrote: On Fri, 24 Feb 2023 at 17:12, Michael Bien wrote: We could skip 1.2 if you want and go right to master and develop it there, no? ... Regarding testing... As you probably know, github actions build the 'release' cluster config in a matrix, ... I was with you initially on skipping 1.2. However, the other approach to this might be a Rust branch and an active (unmerged) PR from there to master. Like we do with sync PRs. That runs the tests when anything is merged into the branch. The Rust modules / cluster can then be included in the release cluster config within that branch for testing purposes? Until we decide it's ready to merge to master, and we have to decide whether to include in the release. good idea! (Although I wouldn't recommend to do that "forever". The more eyes we have which look at the code the better, and 99% of the devs going to have master checked out/built/tested etc.) -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: Documentation Review Questions
Agreed! We'll need a sample code repo... and sample code! :-) Cheers, Antonio On 25/2/23 18:19, Michael Bien wrote: some tutorials link to archive.org I believe. But this is just a workaround and shouldn't stay like that IMO. Sooner or later we are going to need a sample code repo - I agree. - 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: Documentation Review Questions
Hi, At the time the migration was done AsciiDoc looked like a great system for building documentation sites. Then Antora [1] was born and this ratified the choice, I think. I think it would be great if we could adapt the asciidoc tutorials to use Antora. Antora has an integration with both Lunr and with Algolia [2] for building great search capabilities. Algolia is free for open source projects. The only problem with Antora is that is complex to use. In any case the netbeans-website currently accepts html, asciidoc and, of course, markdown. So, yes, you could use Markdown for tutorials. Hope this clarifies, Antonio [1] https://docs.antora.org/antora/latest/asciidoc/asciidoc/ [2] https://www.algolia.com/es/ On 25/2/23 14:55, Sean Carrick wrote: Curiosity: Why is AsciiDoc being used instead of Markdown? - 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: Documentation Review Questions
Hi, Old tutorial project source code is not available, and licensing/provenance is not clear either, I think. I think it's a good idea to have the source code available, under a proper Apache License, and we should update it to match the latest Apache NetBeans module structure, which has changed after the migration. Otherwise people will get confused when the modules they need are different from those in the tutorials. I also think it's a good idea to have a separate repository for tutorials/examples. Cheers, Antonio On 25/2/23 15:35, Sean Carrick wrote: One more question: Do we have a repository set up for the tutorial project source code? I'm noticing that a lot of the tutorials point to the WayBack Machine for getting the project sources, but that does not always work, as Web Archive doesn't always walk the entirety of the website's folder structure and, quite often, the source trees are not included in the archive. -SC - 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?
Hi all, So to summarize, if I understand correctly: 1. We want Rust or other experimental stuff in the main repo. 1.1. I'll make a PR in a few days (once I domesticate the grammar). 1.2. We want it in a "rust" branch first to fine-tune. 1.3. Then we may want to merge "rust" to "master" in: 1.3.1. Option I: A "rust" cluster? 1.3.2. Option II: Or an "experimental" cluster? (in any case disabled in cluster.properties) 2. We may want to release these as plugins. Does this make sense? Thanks, Antonio On 17/2/23 12:57, Neil C Smith wrote: On Fri, 17 Feb 2023 at 11:32, Michael Bien wrote: we could hide the feature a little bit during beta, e.g keep the modules disabled by default and print a warning notification that this is an experimental feature when someone enables the modules. Possibly. Make that b.5 though! 😄 I actually meant to have in a cluster that is not built by default or included in releases at all - similar to contrib, but for our own in-development things. Unless rust deserves its own cluster anyway in future? Could still publish from there to an update centre? - 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 vote form - (was: single vote thread ...)
Hi Neil, all, Apologies for posting in the wrong thread. I think that adding instructions/a checklist in a wiki page is a great idea (things have many buttons now to press :-)). Thanks, Antonio On 18/2/23 10:37, Neil C Smith wrote: I think we should possibly extract the instructions into a wiki page we can link to anyway, and keep the email and response form short? - 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] single vote thread for NetBeans 17
Hi, I have voted using the template, I think we should rephrase it somewhow. It's too verbose to clearly understand. Maybe next time we want to clarify what are mandatory actions (should I check signatures of the main thing being voted on? Any others?) and optional ones. A clear checklist would indeed help, something like this: [ ] Mandatory: Check that https://./netbeans.zip is well signed. 1. Download https://...KEYS. 2. Use "gpg --import KEYS" to import gpt keys. 3. Download https://netbeans.asc 4. Verify using "gpg --verify netbeans.asc netbeans.zip" [ ] Mandatory: Check that netbeans.zip compiles 1. Unzip netbeans.zip somewhere. 2. Run "ant" there. 3. Run "ant tryme" there. [ ] Optional: Build a Maven app to print "Hello, World!" to the console 1. You know how to do this. Or something like that. The easier we make this to understand for friday-night, very-tired, eyestrained voters the more the voters we're gonna have. Cheers, Antonio P.S.: I don't know how to test maven artifacts / vscode. Can take a look at the generated files, though. On 10/2/23 19:43, Neil C Smith wrote: Eric and I have put together a vote email template here - https://cwiki.apache.org/confluence/display/NETBEANS/Voting+template - 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 17
[X] yes / +1 [ ] no / -1 (please justify -1) [ ] binding (member of PMC) My vote is based on [X] I have built and tested the source with OpenJDK Runtime Environment Corretto-11.0.17.8.1 on GNU/Linux 5.15.0 [X] I have tested the binary zip with OpenJDK Runtime Environment Corretto-11.0.17.8.1 on GNU/Linux 5.15.0 [ ] I have tested the installer(s) with on [ ] I have tested the Maven artefacts [ ] I have tested the VSCode extension Great job! Congratulations! Antonio On 16/2/23 16:13, Neil C Smith wrote: This is our first voting candidate for the release of Apache NetBeans 17. 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 17 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/17/ They were built by the Jenkins pipeline : https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/netbeans/job/release170/21/ NB. ignore the build showing as aborted - caused by cancelling push to nightlies. We are primarily voting on : https://dist.apache.org/repos/dist/dev/netbeans/netbeans/17/netbeans-17-source.zip SHA512 : 0a40d0ff3b736ee7b433fec5b5ad4468d5ab2afe68bd284daf3ed135776db773ac91c8f61ebefe6e5101ea16dc7a2407769345108546946f7a218d30416df794 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/17/ Binaries associated with the source - netbeans-17-bin.zip as well as update content under the nbms folder. -- at https://dist.apache.org/repos/dist/dev/netbeans/netbeans-installers/17/ An installer for macOS handcrafted using build resources on a PMC member's macOS machine. An installer for Windows signed by a PMC member using binaries created during the build process. 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/17.0/ The VSCode extension signed by a PMC member using binaries created during the build process. Maven Artefacts The Maven artefacts for Apache NetBeans 17 are ready on staging associated to this vote. https://repository.apache.org/content/repositories/orgapachenetbeans-1125/ The version is : RELEASE170 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 17 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 source with on (required) [ ] I have tested the binary zip with on [ ] I have tested the installer(s) with on [ ] I have tested the Maven artefacts [ ] I have tested the VSCode extension Additional info (optional) - any specifics on w
Re: Rust, anyone?
Hi again, So, to clarify: a) I don't think Rust support is ready yet to be merged with core: it's in alpha state ([1] details some aspects that need work). b) If we want to add Rust support to NetBeans we have to decide the best way: b.1) Create a "rust" branch in the main repo, add code there and keep on improving it until things are ready to merge in core. b.2) Create a repo of ours and let "rust" be an experimental plugin, and keep on improving it there. b.3) Keep on upgrading in my cloned repo until we're all happy. We could start by deciding which option in "b)" best suites us. This may apply also to future "NetBeans experiments" that we may want to get involved into. Cheers, Antonio [1] An assorted list of bugs and features that we could add to Rust: 1. Lexer/Parser bugs 1.1. Lexer/parser are too detailed for an IDE, I think. We may not be interested in lexing the internals of a comment, for instance. We may want to simplify things. 1.2. We should recover nicely from Antlr4 lexer/parser errors. We currently don't. (add arbitrary text to a .rs file and see how it fails) 2. Project/Properties/Licenses The "Project/Properties/Licenses" (dependency to Ant Projects) dialog opens, let's you choose a license, but then forgets. Licenses are never applied to new files. 3. Project/Properties/Other We need customizers for Rust projects. Choosing between Debug and Release configurations, for instance. 4. Workspaces Rust projects with workspaces (such as https://github.com/rust-lang/regex) show the different Rust submodules in the "Sources" node. We may want to handle these as we do with "Maven Submodules". 5. Fonts & Colors We want to add more fonts-colors to different tokens (macros, etc.) 6. Folding Folds work for code blocks, but structs is missing. 7. Debugging Before adding debugging, we need to extract the "gdb" support from the "cnd" branch and add it somewhere in NetBeans. Maybe "ide/gdb*" is a good destination? 8. Semantic HL We may want to add semantic highlighting to different parts of the Rust code (special coloring for mutable reference variables, for instance). 9. Options dialog To select the "cargo" path. 10. Fonts and Colors dialog With a sample .rs file, so people can modify fonts-colors easily. 11. Code completion Of course. "rust-analyzer" (https://rust-analyzer.github.io/) is a popular LSP server, I think. On 15/2/23 22:21, Antonio wrote: Hi, It's currently integrated in my repo 😄. Whether this goes to core and is released as a plugin is not clear yet, I think. That needs some thought. Releasing it as a plugin has the advantage that it can have a different lifecycle than the core. On 15/2/23 19:48, John Kostaras wrote: This is integrated into the core. - 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?
Hi, It's currently integrated in my repo :-). Whether this goes to core and is released as a plugin is not clear yet, I think. That needs some thought. Releasing it as a plugin has the advantage that it can have a different lifecycle than the core. On 15/2/23 19:48, John Kostaras wrote: This is integrated into the core. @antonio I will try to add this functionality I proposed. 😄 All help welcome! - 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: switch to: Require approval for all outside collaborators
Excellent job! Thank you! We've now saved lots of trees being burned for nothing all around the globe. Kind regards, Antonio On 14/2/23 7:20, Michael Bien wrote: infra now made it the default for all apache projects, not only for our netbeans repo. (there is still the option to switch it back via a ticket for individual projects) pretty good result I would say! 😄 - 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?
Hi László, Thanks for the pointer, I was taking a look at that very line too. To clarify, the original Rust grammars by the Rust Team ignore the ">>" lexer token [1] and let the parser decide [2],[3] if that is valid or not depending if we're analyzing an expression or a type parameter: Expression with shift right) "a >> 3;" Type pameter) "> ();" From my point of view we should indeed _lex_ the ">>" token (same for "<<") and decide in the _parser_ whether the ">>" is a valid grammar construct or not. After all we're building an editor, not a compiler. In any case we should be ready in "AbstractAntlrLexerBridge" to detect these sort of hacks and avoid firing the assertion in [4] (taking care of that assertion in [5] "LexerInputCharStream"?) otherwise bad things happen to the event dispatch thread and NetBeans freezes somehow. Cheers, Antonio [1] https://github.com/antlr/grammars-v4/blob/6e0c97aaf0e3149c59b69335f9f75b5a0993e32f/rust/RustLexer.g4#L302 [2] https://github.com/antlr/grammars-v4/blob/6e0c97aaf0e3149c59b69335f9f75b5a0993e32f/rust/RustParser.g4#L1086 [3] https://github.com/antlr/grammars-v4/blob/6e0c97aaf0e3149c59b69335f9f75b5a0993e32f/rust/Java/RustParserBase.java#L8 [4] https://github.com/apache/netbeans/blob/c084119009d2e0f736f225d706bc1827af283501/ide/lexer/src/org/netbeans/spi/lexer/LexerInput.java#L257 [5] https://github.com/apache/netbeans/blob/d1c39135a852a579f32344e486d72d5e0647317b/ide/lexer.antlr4/src/org/netbeans/spi/lexer/antlr4/LexerInputCharStream.java#L52 On 15/2/23 2:15, László Kishalmi wrote: That could be due to virtual tokens (ANTLR token with no length) Maybe I've done something insufficient here: https://github.com/apache/netbeans/blob/15ad55e3f28727e64a4642971f3a980b538c6d4d/ide/lexer.antlr4/src/org/netbeans/spi/lexer/antlr4/AbstractAntlrLexerBridge.java#L152 - 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?
Sure! I'm currently having fun with the SHL/SHR [1] operators in the Lexer, though. Cheers, Antonio [1] https://github.com/antlr/grammars-v4/blob/master/rust/RustLexer.g4#L302 On 14/2/23 22:33, John Kostaras wrote: Click on *Tools → Options* or *NetBeans → Preferences* (Mac) --> *Rust* . - 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)
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! 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? Thanks, Antonio P.S.: Apologies if this has been asked before. - 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?
Hi, Well, the Antlr4 lexer/parser works pretty well, but from time to time it throws an AssertionError [1] and freezes NetBeans, so it needs more work. Detecting test cases (by opening random Rust projects) and detecting where things break is useful. But there're lots of things to do: improve syntax coloring (macros, for instance, could be in another color, and numbers), add code folds for structs, etc. Cheers, Antonio [1] https://github.com/apache/netbeans/blob/c084119009d2e0f736f225d706bc1827af283501/ide/lexer/src/org/netbeans/spi/lexer/LexerInput.java#L257 On 13/2/23 19:33, Jakub Herkel wrote: Antonio, is there any list of things that you want (need) to implement? Maybe someone (me also) can take some of them. Jakub - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Bill of Materials POMs for Netbeans Modules
Hi Edwin, I was pointing to two old threads that talked about adding BOMs to NetBeans that Neil was talking about. The fact is that we don't have a BOM yet. But contributions are welcome :-). Cheers, Antonio On 12/2/23 17:28, Edwin F. wrote: Can I please have the url where these boms are available? I'm interested initially in the bom that has the required dependencies for the database module to work on its own. - 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?
Thanks Michael! D'oh! My intents to add Rust to the NetBeans core (very much as in the Linux kernel case) have been detected! :-D Latest commits solve these issues, though (and add new bugs). Next challenge: Cargo workspaces [1]. Cheers, Antonio [1] https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html On 12/2/23 9:03, Michael Bien wrote: for others who want to give it a try: I had to fix two things to make the build pass: - removed references of RustPackage in org.openide.nodes.Node (probably a happy coding accident) - had to create this folder: netbeans/rust/rust.project/test/unit/src - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: How to incorporate MIT source code?
Thanks, Laszlo, I've updated the "licenseinfo.xml" (adding the proper license in nbbuild/licenses. Question is, shall I mantain the original MIT license header in the file as well as the Apache one such as in [1]? On other news, I generate the grammars at build time with [2] (using the org.antlrv4.Tool in build.xml). Thanks, Antonio [1] https://github.com/vieiro/netbeans-cnd/blob/285b1cd5192ba57852e01c0b01057a772d83c6a1/rust/rust.grammar/src/org/netbeans/modules/rust/grammar/antlr4/g4/RustLexer.g4 [2] https://github.com/vieiro/netbeans-cnd/blob/285b1cd5192ba57852e01c0b01057a772d83c6a1/rust/rust.grammar/build.xml On 11/2/23 9:03, Laszlo Kishalmi wrote: Here is an example: https://github.com/apache/netbeans/blob/master/java/languages.antlr/licenseinfo.xml MIT is a pretty permissive license, AFAIK it can be used without restriction. See the nbbuild/licenses folder for examples. - 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?
Hi again, For those interesed, an alpha version (under heavy refactoring) is available at https://github.com/vieiro/netbeans-cnd/tree/rust Buildable with "ant -Dcluster.config=rust" Cheers, Antonio P.S.: Of course, you need Rust's "cargo" on your command line to make any use of it. On 11/2/23 15:54, Antonio wrote: I have a minimal cluster with Rust support, but I'm not sure I'll be able to maintain it. Maybe a plugin is a better idea? - 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
Rust, anyone?
Hi all, Is there interest in adding Rust support to NetBeans? I have a minimal cluster with Rust support, but I'm not sure I'll be able to maintain it. Maybe a plugin is a better idea? Thanks, Antonio - 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] single vote thread for NetBeans 17
+1 In fact, let's make this a big +1: _ _| |_ || |_ _| | | |_|| | | | | | |___| On 10/2/23 19:43, Neil C Smith wrote: Due to previously discussed issues and delays caused by running multiple voting threads on the various convenience binaries, we'd like to try a single voting thread covering all artefacts for NetBeans 17. - 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: Bill of Materials POMs for Netbeans Modules
Yep, Bill of Materials have been around for a long time now... - 2020 https://lists.apache.org/thread/xqf041nzhl1rwvh4gosqkg19h43g9fl6 - 2022 https://lists.apache.org/thread/ll2xq0mrbdw9y3rwm1gpnf7ovc2ld4rf Cheers, Antonio On 10/2/23 12:22, Neil C Smith wrote: Yes, Eric and I had a conversation ages ago about the possibility of replacing or augmenting the cluster poms with a bill of materials. I started looking at the process for generating, but other things, etc. etc. took priority and I never did get around to it. - 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 incorporate MIT source code?
Hi all, Imagine I need to use some source code released under the MIT license (say an Antlr Grammar [1]) and make modifications to it, and cover these modifications with the Apache License. How am I expected to do this? I mean, a) Shall I keep the original license in a commit, so it can be tracked in the future, and then replace the license with the Apache License and continue with modifications in future commits? That won't do, because commits are only for Apache-2 license, right? b) May I keep the original MIT license and keep on using this license? That won't do eiher, for the same reason as above. c) Maybe keeping tracking of licensing history in a licenseinfo.xml somehow? d) Any other ideas I can't think of? Thanks, Antonio [1] https://github.com/antlr/grammars-v4 - 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: tests question
Unit tests! Some examples here: https://netbeans.apache.org/tutorials/nbm-test.html On 7/2/23 10:40, name name2 wrote: Hello What type of tests do i need to make before PR? ant: test/test-basic/test-platform/other? - 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: Usage of DateTimeFormatter forbidden
Hi name name2, The statement that "Usage of DateTimeFormatter forbidden" is not correct. On 7/2/23 18:59, name name2 wrote: Hello https://github.com/apache/netbeans/pull/5445 SDT deprecated by fact of existing new java.time By SDT I understand that you mean SimpleDateFormat. The fact that you don't like SimpleDateFormat does not mean it's deprecated (nor that we "forbid" the usage of DateTimeFormatter, nor that we're going to change it everywhere in such a huge codebase). SDT isnt thread safe and required ThreadLocal. The most part of code is The fact that you've seen a "static SimpleDateFormat" somewhere does not mean that there's a thread issue. The static field can be used in a thread safe manner (on a single thread, for instance). Your evaluation of the problem is non existing. without TL or created new objects every request. Its doesnt effective and right way. Also TL required a lot of memory as i know and are not desirable because they complicate the logic. As explained in other threads, NetBeans is both an IDE and a platform. You can't change public APIs happily. All PRs that change the public NetBeans API (including the one you refer to) without previous discussion on the mailing list will be rejected. Also, as explained by other people in some other PRs, the advice to you is to discuss potential problems in the mailing list _before_ actually submitting PRs. By discussing I mean explaining a potential problem, not complaining because your PRs have been closed. Finally note that this is an open source project, not a programming contest where you're expected to show the world how well you program in Java. We're happy to have good Java programmers submitting PRs, but we also expect contributions to contribute value, to solve problems and to improve NetBeans, understanding what the problem is dinamically (more than statically), and not changing things because of personal preferences. Cheers, Antonio - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSSION] integrating cleanup PRs
Hi Michael, Refactoring the code because of aesthetic, academic or modernization reasons is a non-ending task in a >500KLOC codebase that will turn 27 this year. By the time we end up modernizing all the code it will then be outdated. IMHO we need contributors that are conscious of the implications of the changes they propose, that run this extra mile that requires thinking and explaining us the pros and cons, and the value they want to add to the project. IMHO it's our responsibility to request these explanations to contributors, otherwise we'll end up stuck in a never-ending loop of reviewing a codebase that will turn 27 this year. These discussions, as you say, should be done in the mailing list, and not in a PR _after_ the code has been submitted. Cheers, Antonio On 27/1/23 17:42, Michael Bien wrote: [...] Another example are generics, which is super tiresome to review - this has to be split up. - 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: Arrays.asList...stream to Arrays.stream
Hi, So what is the value added if you submit this change? Is this a ten element list or a ten hundred thousand element list? Is this running inside a loop? What are the pros and cons of this change? Is this going to win ten manoseconds or ten minutes in running time? Thanks, Antonio On 29/1/23 6:59, name name2 wrote: toURLs( Arrays.asList(prjs).stream().flatMap( (prj) -> Arrays.asList( AntArtifactQuery.findArtifactsByType(prj, JavaProjectConstants.ARTIFACT_TYPE_JAR) ).stream()). flatMap((a) -> Arrays.asList(a.getArtifactLocations()).stream()). collect(Collectors.toList()) ); to toURLs( Arrays.stream(prjs).flatMap( (prj) -> Arrays.stream( AntArtifactQuery.findArtifactsByType(prj, JavaProjectConstants.ARTIFACT_TYPE_JAR) )). flatMap((a) -> Arrays.stream(a.getArtifactLocations())). collect(Collectors.toList()) ); Its ProjectClassPathModifier.java 8 files changed: - extide\gradle\src\org\netbeans\modules\gradle\loaders\ExtensionPropertiesExtractor.java - groovy\groovy.editor\src\org\netbeans\modules\groovy\editor\api\parser\GroovyParser.java - ide\db\src\org\netbeans\api\db\explorer\ConnectionManager.java - java\java.project\src\org\netbeans\api\java\project\classpath\ProjectClassPathModifier.java - nb\autoupdate.pluginimporter - src\org\netbeans\modules\autoupdate\pluginimporter\Installer.java - test\unit\src\org\netbeans\modules\autoupdate\pluginimporter\InstallerTest.java - o.n.upgrader\src\org\netbeans\upgrade\AutoUpgrade.java - test\unit\src\org\netbeans\upgrade\AutoUpgradeTest.java Can i make PR or not? - 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: switch to: Require approval for all outside collaborators
+1 I think ASF Infra will be happy to reduce the consumption of resources. AFAIK Github (Microsoft) allocates a finite number of running hours for Github Actions to the ASF. The wiser we spend these, the better. Cheers, Antonio On 28/1/23 22:19, Michael Bien wrote: Hi devs, gh has a setting which controls when workflows need approval before they run, the default seems to be: "require approval for first-time contributors" or at least this is the setting the netbeans project is running on. I would like to contact apache infra and ask if we could switch this to: "Require approval for all outside collaborators" - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSSION] integrating cleanup PRs
Hi,
I'd try to take a look at them during the weekend, as time permits.
I've seen tons of "code cleanup" PRs that have very little value and are
too granular.
- Changing "new Integer(0)" with "0" in three files in a project with >
500k LOC is not worth the effort and does not provide real value.
- Changing "new String("Hello")" with "Hello" makes sense only if you're
allocating tons of Strings (in a loop, for instance), but not in a
method that you call each ten minutes.
On the contrary, these PRs consume reviewers' time and burn trees
running our 3-flavoured JDK CI/CD pipelines for very little value. Not
worth running those heavy pipelines for just three syntactic sugar
issues in three files.
I'd ask these people concerned with "syntactic sugar" issues to group
those little commits in a single PR, that can be reviewed at once and
that is worth running a single CI/CD run.
Cheers,
Antonio
P.S.: We may also want to define what "readability" means for us.
There're people modifying test code because they think that static
imports are more readable than normal imports. In my book (doing Java
for more than twenty years) I don't see any advantage in using static
imports, on the contrary, you have to scroll up and see what is static
imported.
On 26/1/23 18:59, Michael Bien wrote:
Everyone is invited to review them for correctness and also whether or
not they are actually worth it. Just because there is an easy to use
code inspection available for something doesn't mean we should run it on
400+ projects blindly. This is also part of the problem: Running code
inspections is trivial, reviewing them however is time consuming.
-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [External] : Re: [DISCUSS] Future of cpplite projects
Hi, I can't tell if this would work on a running NetBeans instance, though, because cpplite.editor is loaded through the general classloader under certain circumstances [1]. It seems "cpplite.editor" is also required for OpenJDK debugging? We could also release cnd in a "NetBeans C++ edition", for instance, possibly with a different release cadence and a smaller subset of clusters. Cheers, Antonio [1] https://github.com/apache/netbeans/blob/master/java/java.openjdk.project/src/org/netbeans/modules/java/openjdk/project/CProjectConfigurationProviderImpl.java#L57 El 4/10/22 a las 21:46, Geertjan Wielenga escribió: Well, maybe on installing CND, the CCPLITE modules should get uninstalled and vice-versa. 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: [External] : Re: [DISCUSS] Future of cpplite projects
Hi all, A quick update on the status of cnd and cpplite. 1. Both cnd and cpplite want to register different stuff for the text/x-c++, text/x-c, text/x-h, etc. mimetypes. 1.1. I tried to create "text/x-c++-cpplite", "text/x-c-cpplite" (etc) mimetypes by trying to see if a FileObject belongs to a CND project or a cpplite project. This would be the cleanest approach to keep cnd and cpplite happy, but I didn't get it. 1.2. I then dropped the cpplite editor so only cnd registers mimetypes. This worked well, but both cnd and cpplite register breakpoints in the editor in different ways, for the same mimetype [1], so cpplite breakpoints didn't work. 2. I then checked out cnd, merged latest master, dropped cpplite and cnd seems to build and work perfectly. El 16/5/22 a las 14:59, Martin Balin escribió: I would really like to keep CPPLite inside NetBeans. It is used for GraalVM Native Image debugging to work with GDB and adapting this feature to work CND will be overkill also with respect to size of CND. If needed then CPPLite project can be removed to mix with CND. Martin So after all these tests I think making cpplite coexist with cnd is going to be impossible (any hints welcome, of course). cpplite also registers a LSP server for both text/x-c and another one for text/x-c++, so projects that mix both C and C++ will probably restart the LSP server when users change focus between C and C++ files. That may be a problem users are reporting in the nbusers mailing list. By the way, I'd like to know how to run a "GraalVM Native Image" debugging session. Since I have little spare time for NetBeans lately I'd appreciate instructions on how to do this. Kind regards, Antonio [1] Actions provider in CPPLITE: https://github.com/apache/netbeans/blob/master/cpplite/cpplite.debugger/src/org/netbeans/modules/cpplite/debugger/breakpoints/CPPLiteBreakpointActionProvider.java#L43 Actions provider in CND: https://github.com/apache/netbeans/blob/cnd/cnd/cnd.debugger.common2/src/org/netbeans/modules/cnd/debugger/common2/debugger/actions/ToggleBreakpointActionProvider.java#L62 - 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
Hi Eric, Great job! El 8/8/22 a las 19:51, Eric Barboni escribió: 3) Copy from webarchive to our site but I'm unsure of the copyright here. 4) other idea 4) Update the content from webarchive, rewriting/summarizing it to match current NetBeans (for instance, many content from lexer.netbeans.org is obsolete). Copyright would then be Apache's. Cheers, Antonio - 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?
Hi there,
The link you posted a while back [1] has now expired, but I recall
seeing a "synchronized(CantRememberClass.class) {}" there (two, in fact,
intermingled with what looked to me as an async code call).
Can you please post the link again?
Thanks,
Antonio
[1]
https://pipelines.actions.githubusercontent.com/serviceHosts/3cf2747f-b5d6-4e8e-a999-150ff8ae61e1/_apis/pipelines/1/runs/14001/signedlogcontent/7?urlExpires=2022-05-29T17%3A16%3A59.2143803Z&urlSigningMethod=HMACV1&urlSignature=f%2B%2BJVlE0n3fHCqA4wJkq4iKPdD%2B502hC2csZJFs5keE%3D
El 9/6/22 a las 20:31, Matthias Bläsing escribió:
I don't even know where to start with this - maybe you have an idea
what could happen here?
-
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 4.8 and nb-repository 1.7)
+1 (binding) Checked signatures, NOTICE, LICENSE look ok to me. Quick look at sources looks good. For those using linux, the script below may speed up verification. Cheers, Antonio [1] sh script.sh https://dist.apache.org/repos/dist/dev/netbeans/netbeans-maven-utilities/nbm-maven-plugin/nbm-maven-plugin-4.8/nbm-maven-plugin-4.8-source-release.zip --- #!/usr/bin/env sh if [ $# -ne 1 ]; then echo "Usage: verify-signature URL" echo " Verifies that URL is signed properly with URL.asc and URL.sha512" exit 1 fi FILE=`basename $1` echo "Verifying signatures of $FILE" CURL=`which curl` if [ "X" = "X$CURL" ]; then echo "curl not found on path. Please install it." exit 2 fi SHA512=`which sha512sum` if [ "X" = "X$SHA512" ]; then echo "sha512sum not found on path. Please install it." exit 2 fi echo "Downloading $1 ..." $CURL -s $1 -o $FILE if [ $? -ne 0 ]; then echo "Could not download $1" exit 3 fi echo "Downloading $1.asc ..." $CURL -s "$1.asc" -o $FILE.asc if [ $? -ne 0 ]; then echo "Could not download $1.asc" exit 4 fi echo "Downloading $1.sha512 ..." $CURL -s "$1.sha512" -o $FILE.sha512 if [ $? -ne 0 ]; then echo "Could not download $1.sha512" exit 5 fi RESULT_SHA=`$SHA512 $FILE` EXPECTED_SHA=`cat $FILE.sha512` if [ "X$EXPECTED_SHA" != "X$RESULT_SHA" ]; then echo "SHA512 sums fail" echo "RESULT : $RESULT_SHA" echo "EXPECTED: $EXPECTED_SHA" exit 6 else echo "*** ***" echo "*** SHA512 sum matches. ***" echo "*** ***" fi gpg --verify $FILE.asc $FILE if [ $? -ne 0 ]; then echo "PGP signature check failed." exit 7 else echo "*** ***" echo "*** PGP signature is ok. ***" echo "*** ***" fi --- El 3/6/22 a las 18:49, Eric Barboni escribió: Thanks a very last PMC vote and this one could be closed. Eric -Message d'origine- De : Michael Bien <> Envoyé : jeudi 2 juin 2022 14:47 À : dev@netbeans.apache.org; Eric Barboni Objet : Re: [VOTE] Release of Apache NetBeans utilities (nbm-maven-plugin 4.8 and nb-repository 1.7) +1 (binding) - i haven't tested it, but looking through the PRs you linked (for #1) its unlikely that they break anything, they are minor updates - #1, #2 builds fine with JDK 18 (mvn clean verify) - both sigs OK best regards, -mbien On 02.06.22 13:17, Eric Barboni wrote: +1 (binding) I need 2 more bindings vote Best Regards Eric -Message d'origine- De : Eric Barboni <> Envoyé : mardi 31 mai 2022 18:56 À : dev@netbeans.apache.org Objet : [VOTE] Release of Apache NetBeans utilities (nbm-maven-plugin 4.8 and nb-repository 1.7) Hi folks I would like to release the final artefacts for the Apache NetBeans utilities. ### 1 nbm-maven-plugin 4.8 -- Main changes Add tsaurl and tsacert options when signing nbms by Andrew Scott Gardner https://github.com/apache/netbeans-mavenutils-nbm-maven-plugin/pull/21 Include runtime module libraries Axel Hauschulte (as an option) https://github.com/apache/netbeans-mavenutils-nbm-maven-plugin/pull/28 A bit of dependencies changes. Integration Test are ok Artefacts: https://dist.apache.org/repos/dist/dev/netbeans/netbeans-maven-utiliti es/nbm -maven-plugin/nbm-maven-plugin-4.8/ Sha512 4d8fb07d052059fd348a17ff20739f5a36289fba569969b6bfdf74a0f576e322cf1b3a 54b854 dd0f04ebcad0be1cadee6c58bb483ab350e8399888b0b5dcd613 In addition to that, artefacts build from https://github.com/apache/netbeans-mavenutils-nbm-maven-plugin commit id (3c03efecae0fb3c4b146de77bf65fe121fd00b30 tag nbm-maven-plugin-4.8) are staged in [1] ### 2 This plugin is used to get the Apache NetBeans artefacts ready for maven central. It's been a long time since release (2020). We changed the way we look to external dependencies to get the one from maven central if sha1 match. A bit of dependencies changes. Integration Test are ko but the goal associated is no more available (forget they where it but too lazy to respin). Artefacts https://dist.apache.org/repos/dist/dev/netbeans/netbeans-maven-utiliti es/nb- repository-plugin/nb-repository-plugin-1.7/ Sha512 7ff78a88a2364d358c83664b3b2e69689f6a7fc5f47ff9b7a85ecfe0cd448688df9c1e bbf515 c2e5a2c9695c358be2539fa93c72e0e5438f7b087beac74c8bc6 In addition to that, artefacts build from https://github.com/apache/netbeans-mavenutils-nb-repository-plugin commit id (68f94faa4ad38aabc44e1a3f53245f60ab0069e4 tag nb-repository-plugin-1.7) are staged in [1] Key file is here: https://www.apache.org/dist/netbeans/KEYS The vote is open for at least 72h. Best Regards Eric [1] https://repository.apache.org/content
Re: [LAZY CONSENSUS] Reorganize maven-utilities repository into one
Hi,
The "BOM" (Bill of Materials) is a packaging that "defines the
versions of all the artifacts that will be created in the library. Other
projects that wish to use the library should import this POM into the
dependencyManagement section of their POM." [1]
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.
But it may be of interest if someone wants to use just a few modules in
a plain Java application, for instance. You include a dependency with
this BOM, and then you don't have to specify the ${netbeans.version} in
the rest of dependencies.
I may give it a run in the future, and try to build one for NETBEANS140,
for instance.
Cheers,
Antonio
[1]
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms
El 3/6/22 a las 10:13, Eric Barboni escribió:
Hi Antonio,
Do you have some information on this bom concept on maven? Not sure I
understand what it involve
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: [LAZY CONSENSUS] Using Matomo Tracking for our website
D'oh! This has a cookie banner? Then I change my vote to -1. We do have enough of these around! El 2/6/22 a las 23:11, Michael Bien escribió: https://matomo.org/faq/general/faq_2/ mentions that it has opt-out capability. This basically means "cookie banner", IMO the internet has enough of those. - 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] Reorganize maven-utilities repository into one
+1 to this. While we're at it, is a Maven BOM of any use? Cheers, Antonio El 31/5/22 a las 19:18, Eric Barboni escribió: I would like to regroup the maven-utilities repository back into one. I like very much writing voting mail that are longer than the code changes but I would prefer one mail for the all stack on maven utilities artefacts. - 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] Using Matomo Tracking for our website
Hi, +1 to using Matomo. I imagine this will be fast to do. We may want to give the web a redesign, maybe including our build system. Antora looks promising but somewhat complex (Antora is used in some other Apache projects). Also we may want to clean up legacy pages that are not used anymore, and add examples in tutorials based on Apache NetBeans. Lots of things to do on the web! Cheers, Antonio El 2/6/22 a las 14:27, Eric Barboni escribió: I'm not sure we have a lot's of dead link on our page. But we may have link to our page from external site that are hard to fix without tracker. I guess there are also other usage with heatmap on page and so one. - 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
I couldn't reproduce the "org.netbeans.Stamps" any more, so I'd go for friday. El jue, 19 may 2022 a las 17:06, Eric Barboni () escribió: > > 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? > > Best Regards > Eric > -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). > > > > > > >
Re: [External] : Re: [DISCUSS] Future of cpplite projects
Hi Martin, cpplite.debugger uses some debugger classes in an external file [1], and we can drop this dependency and substitute it with a dependency with the cnd.debugger.common2 and cnd.debugger.gdb modules directly without problems, I think. As stated in [2] cpplite.project stores project information in userdirs (preferences), so I don't know how a team can exchange projects (in git, for example). Note also that in [2] Jan suggested to drop data loaders too, but we may want to keep them in order to make the debugger work fine with cpplite projects. Is there any use case you can share (a sample project, for instance) so I can see how to keep cpplite and cnd working together? Thanks, Antonio [1] cpplite/cpplite.debugger/external/cpplite-mi-1.0-SNAPSHOT.jar [2] https://lists.apache.org/thread/zlf78ryof5d3cg4g2gh3dsx0fzrjhrgj El 16/5/22 a las 14:59, Martin Balin escribió: Hi, I would really like to keep CPPLite inside NetBeans. It is used for GraalVM Native Image debugging to work with GDB and adapting this feature to work CND will be overkill also with respect to size of CND. If needed then CPPLite project can be removed to mix with CND. 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
[DISCUSS] Future of cpplite projects
Hi all, So we have now a "cnd" branch with Makefile based projects, etc. and LSP server support (with clangd), that adds semantic highlighting, hints, completion, etc. Question is, since cnd Makefile based projects supersede cpplite based ones, what do we want to do with cpplite projects? Do we want to remove these or not? I did a small experiment trying to remove cpplite at [1] but it seems the cpplite project structure is being used in "java/java.openjdk.project" via the general classloader. Do we want to move these "cpplite" project structure somewhere in the "ide" cluster? Thanks Antonio [1] https://github.com/apache/netbeans/pull/4114 [2] https://github.com/apache/netbeans/blob/6543326b16fdcb05092fbb7af86fe817a07586b3/java/java.openjdk.project/src/org/netbeans/modules/java/openjdk/project/CProjectConfigurationProviderImpl.java#L61 - 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
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/lastCompletedBuild/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 draft: > > > > > > https://github.com/apache/netbeans/pull/4070 > > > > > >
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 draft: > > > > https://github.com/apache/netbeans/pull/4070 > > > > -michael > > > >> > >> whatever you prefer - don't know what the others think. > >> > >> best regards, > >> > >> michael > >> > >> > >>> Eric > >>> > >>> -Message d'origine- > >>> De : Neil C Smith <> > >>> Envoyé : lundi 2 mai 2022 18:45 > >>> À : dev@netbeans.apache.org > >>> Objet : Re: [RELEASES] Issue on delivery merge > >>> > >>> On Mon, 2 May 2022 at 17:11, Matthias Bläsing > >>> wrote: > >>>> ebarboni force-pushed the delivery branch from 74e1e5f to 217f7df 4 > >>>> days ago (2022-04-28 13:58 CEST) > >>> .. > >>>> - get a list of all closed PRs on github with a change date in the > >>>> last 4-5 days > >>> Also, a reversed way which correlates is to use > >>> https://github.com/apache/netbeans/commit/74e1e5f91c48df7a06154781bcf > >>> 17da397a589a8 > >>> > >>> and follow the parent links - only those two PRs have a warning that > >>> the commit isn't in delivery. > >>> > >>> Neil > >>> &g
Re: travis weather report: stuck
Quoting from [1] "GitHub contacted Heroku and Travis-CI to request that they initiate their own security investigations, revoke all OAuth user tokens associated with the affected applications, and begin work to notify their own users." So even though the attack was last month, maybe Travis-CI is still doing some pruning/reviews of accounts, looking for attack vectors or something. Cheers, Antonio [1] https://github.blog/2022-04-15-security-alert-stolen-oauth-user-tokens/ El 12/5/22 a las 4:21, Michael Bien escribió: travis appears to be stuck again, 10 PRs in the build queue and nothing is building. - 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: removing SPARC support
Hi Brad, ex-Sun here as well, so emotional attachment too :-). I think we should keep SPARC support for at least one (or more) Apache NetBeans releases. SPARC users deserve it. And who knows, we may have at least one user ;-). Last March Oracle announced Solaris 11 CBE [1], free for use for open source developers and non-production use. Looking at the license [2] though, it's not clear if we can use it to generate "production ready" binaries for Solaris. If it were possible then I assume we could ask ASF-Infra to generate one virtual machine for us (it license allows) so we can use it as a "build-bot" for Solaris binaries. Or, since binaries are rarely changed, we could rebuild binaries for Intel/SPARC in a VirbualBox VM, for instance (cross-compiling for SPARC in Intel). Kind regards, Antonio [1] https://blogs.oracle.com/solaris/post/announcing-the-first-oracle-solaris-114-cbe [2] https://www.oracle.com/downloads/licenses/solaris-ea-license.html El 12/5/22 a las 1:18, Brad Walker escribió: I've been having a conversation about removing Solaris SPARC support from the CND (i.e. C/C++) branch. As you might know, there is active work on getting this into the master branch. I started removing support Solaris SPARC and several individuals mentioned that I should ping the development team for comments/feedback/opinions or anything else about this. Here are the relevant details: No more Java support - JEP 381 In 2017, Sun shutdown the SPARC dev. teams and stopped future work on the processor. And here are my comments: "Sun was the first professional co. that I started my career at. I worked on the team that ported SunOS (before Solaris) over to SPARC. It has a deep emotional attachment for me. But, I just can't see anyone using it. It made me sad when OpenJDK officially shut down support for it. It's got a lot of cruft associated with it. So I'm trying to make the code base easier to support. And just so you are aware, I'm expecting to probably be the one supporting it, if it stays around, since I have a working 64bit SPARC machine. Actually several. 8-)" So if you have an opinion on this, I would be really interested in hearing it.. -brad w. - 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
