Re: [VOTE] Release Apache NetBeans 22
Hi, my vote: -- 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 21 (bundled) on Ubuntu 24.04 (required) [X] I have tested the binary zip with OpenJDK 21 (bundled) on Ubuntu 24.04 [X] I have tested the deb installer with OpenJDK 21 (bundled) on Ubuntu 24.04 [X] I have tested the windows installer with Amazon Corretto 17.0.10+7-LTS on Windows 10 [ ] I have tested the Maven artefacts [ ] I have tested the VSCode extension Additional info (optional) - any specifics on what you've tested -- Thanks to all contributors! Greetings Matthias Am Donnerstag, dem 23.05.2024 um 16:43 +0200 schrieb Eric Barboni: > 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
Re: GraalVM: Anyone still interested or do we reduce support to GraalJS or do we switch back to rhino?
Hi Oliver, Am Montag, dem 08.04.2024 um 08:55 +0200 schrieb Oliver Rettig: > I have not really understand the problem and the options to solve them but it > sounds for me that seperating graalvm- and graalVM-based-js netbeans modules > is a good idea? The problem is, that GraalVM/GraalJS (as bundled with NetBeans ) is currently broken on JDK 22. GraalVM uses Unsafe and in JDK 22 some of the used methods were removed from that class. The naive update of GraalVM/GraalJS to 23.0.3 seemed to work, but later showed that it also fails, just slightly different (still accessing Unsafe). So I just tried to force version 24.0.0 into the current module structure. I tried two approaches both failed. Maybe this is a trivial problem for someone knowledgeable, but from my POV this is release critical and the request to fix problems in that area: https://github.com/apache/netbeans/issues/6925 was ignored for the last 3 months. This needs attention from someone with knowledge in the area and if that is not offers, I do see replacing graaljs with rhino as a fallback option. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
GraalVM: Anyone still interested or do we reduce support to GraalJS or do we switch back to rhino?
Hi all, a recent update to the JDK (released in JDK 22) broke GraalJS in NetBeans: https://github.com/apache/netbeans/issues/7245 I tried to update GraalJS for the last three days and at the end I noticed, that the version I was working with broke less obviously, than the old one. So it was useless. I was working with 23.0.3 because after that graalvm changed packaging. Turns out, I should have looked closer. So where to go from here? The dependencies suggested by GraalVM pull in: +- org.graalvm.polyglot:polyglot:jar:24.0.0:compile | +- org.graalvm.sdk:collections:jar:24.0.0:compile | \- org.graalvm.sdk:nativeimage:jar:24.0.0:compile | \- org.graalvm.sdk:word:jar:24.0.0:compile \- org.graalvm.polyglot:js-community:pom:24.0.0:compile +- org.graalvm.js:js-language:jar:24.0.0:runtime | +- org.graalvm.regex:regex:jar:24.0.0:runtime | +- org.graalvm.truffle:truffle-api:jar:24.0.0:runtime | \- org.graalvm.shadowed:icu4j:jar:24.0.0:runtime \- org.graalvm.truffle:truffle-runtime:jar:24.0.0:runtime +- org.graalvm.sdk:jniutils:jar:24.0.0:runtime \- org.graalvm.truffle:truffle-compiler:jar:24.0.0:runtime So we need to rethink the packaging in NetBeans. I see as options: - rip out everything that looks like GraalVM and Truffle and replace it with a single module that only wraps GraalJS - remap the current modules to the new GraalVM structure - drop everything Graal and switch back to rhino I'm a bit fed up about this. The Graal looks a bit less shiny now and the old rhino looks much nicer. The question: How complex are pac Scripts in reality? Is dropping Graal an option? Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [VOTE] Release Apache NetBeans 21
Hi, my vote: -- 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 System OpenJDK 17 on Ubuntu 23.10 (required) [X] I have tested the binary zip with System OpenJDK 17 on Ubuntu 23.10 [X] I have tested the DEB installer(s) with System OpenJDK 17 on Ubuntu 23.10 [X] I have tested the MSI installer(s) with Amazon Corretto 17 on Windows 10 [ ] I have tested the Maven artefacts [ ] I have tested the VSCode extension Additional info (optional) - any specifics on what you've tested -- Thanks to all contributors! Greetings Matthias Am Freitag, dem 16.02.2024 um 17:54 + schrieb Neil C Smith: > This is our first voting candidate for the release of Apache NetBeans 21. > > 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 21 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/21/ > > They were built by the Jenkins pipeline : > > https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/release210/9/ > > > > We are primarily voting on : > > https://dist.apache.org/repos/dist/dev/netbeans/netbeans/21/netbeans-21-source.zip > > SHA512 : > 60533839fe9513e7e4b6f0f8ced77f076a28b89aa3fcc4ea4487a633263d906b8c32b11e8ad4470a820c3a66e795eeb42fb0eda10645414424739a408312bfe5 > > 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/21/ > > Binaries associated with the source - netbeans-21-bin.zip as well as > update content under the nbms folder. > > -- at https://dist.apache.org/repos/dist/dev/netbeans/netbeans-installers/21/ > > 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/21.0/ > > The VSCode extension signed by a PMC member using binaries created > during the build process. > > > > Maven Artefacts > > The Maven artefacts for Apache NetBeans 21 are staged at : > > https://repository.apache.org/content/repositories/orgapachenetbeans-1139/ > > The version is : RELEASE210 > > > > 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 21 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
Re: [VOTE] Release Windows launcher natives version 1-94a19f0
+1 (binding) - Checked LICENSE, NOTICE, checksums, signatures - Build from source on Ubuntu Linux 23.10 (had to adjust a cast, that was rejected by mingw) - Checked that source zip matches contents of git repository Thank you Matthias Am Montag, dem 08.01.2024 um 18:00 + schrieb Neil C Smith: > 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
Re: Language Server Protocol - rust-analyzer
Hi arsi, Am Sonntag, dem 12.11.2023 um 08:14 +0100 schrieb arsi: > > I needed to add good support for Rust to Netbeans because I'm like a trained > monkey, any other IDE kills me. So I added it藍. > so why don't you drop your fork and instead make this a PR that can live within the NetBeans code base? That way it has a chance to live on when you loose interest. For the first part I created: https://github.com/apache/netbeans/pull/6856 to make it easier to integrate rust-analyzer. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: JPA Libraries: to bug report or not to bug report
Hi Stephen, it would have been nice if you would have tested #6748, it is now merged to master and should make it easier to work with JPA in standalone projects in the future. Greetings Matthias Am Samstag, dem 25.11.2023 um 14:04 +0100 schrieb Matthias Bläsing: > Hi Stephen, > > Am Donnerstag, dem 23.11.2023 um 21:10 + schrieb Stephen Parry: > > *We already use Maven* , with the correct dependencies - but the wizard > > only lists the JPA 3.0 support if there is a suitable library available on > > the Tools Libraries screen. > > please have a look here: > > https://github.com/apache/netbeans/pull/6748 > > I understand, that your use-case are not JavaEE/JakartaEE applications, > but standalone applications. For these the change enhances the > persistence provider selection to not only support bundled/legacy > libraries, but also libraries on the classpath. The latter covers maven > dependencies. > > Please see if that fixes your use-case. > > A test build is available from the checks page of the PR: > > https://github.com/apache/netbeans/actions/runs/6984884741 > > or directly: > > https://github.com/apache/netbeans/suites/18481345427/artifacts/1072745346 > > Greetings > > Matthias > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [VOTE] 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 17 (System JDK) on Ubuntu Linux 23.10 [X] I have tested the binary zip with OpenJDK 17 (System JDK) on Ubuntu Linux 23.10 [X] I have tested the DEB installer with OpenJDK 17 (System JDK) on Ubuntu Linux 23.10 [X] I have tested the Windows installer with Amazon Corretto 17 on Windows 10 (jdkhome was manually set with installer argument) [ ] I have tested the Maven artefacts [ ] I have tested the VSCode extension Additional info (optional) - any specifics on what you've tested Am Dienstag, dem 28.11.2023 um 10:46 +0100 schrieb Eric Barboni: > This is our first voting candidate for the release of Apache NetBeans 20. > > Please follow the NEW voting template at the bottom of this email, > and note all requirements below for validating sources and convenience > binaries before voting. > > Apache NetBeans 19 constitutes all clusters in the Apache NetBeans Git > repository, > which together provide the NetBeans Platform (i.e., the underlying > application framework), > as well as all the modules that provide the Java SE, Java EE, PHP, > JavaScript and Groovy features of Apache NetBeans. > > > > Build artefacts are available here : > > https://dist.apache.org/repos/dist/dev/netbeans/netbeans/20/ > > They were built by the Jenkins pipeline : > > https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/release200/16 > / > > > > We are primarily voting on : > > https://dist.apache.org/repos/dist/dev/netbeans/netbeans/20/netbeans-20-sour > ce.zip > > SHA512 : > e795875918022541354213b03d7c4515db81c384f43d0b87029666583064e3093ca1a6ebe8f6 > ffa633c62d02a551be8df52703dfefb830efb8654558ddec5f28 > > KEYS file : https://downloads.apache.org/netbeans/KEYS > > > > Associated with the primary source item we have, generated with the > pipeline mentioned above : > > -- at https://dist.apache.org/repos/dist/dev/netbeans/netbeans/20/ > > Binaries associated with the source - netbeans-20-bin.zip as well as > update content under the nbms folder. > > -- at > https://dist.apache.org/repos/dist/dev/netbeans/netbeans-installers/20/ > > A PKG installer for macOS built and signed with NBPackage on a PMC member's > macOS machine. > An EXE installer for Windows signed by a PMC member using binaries created > during the build process. > DEB and RPM packages for Linux signed by a PMC member using binaries created > with NBPackage during the build process. > > -- at > https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/20.0/ > > The VSCode extension signed by a PMC member using binaries created during > the build process. > > > > Maven Artefacts > > The Maven artefacts for Apache NetBeans 20 are staged at : > > https://repository.apache.org/content/repositories/orgapachenetbeans-1137/ > > The release of maven artefacts is based on a secondary build at > https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/release200/17 > / changing only the plugin nb-repository-plugin that was not populating > pom.xml > > The version is : RELEASE200 > > > > Voting requirements > > Before voting +1 you are required to download the signed source code > package, compile it as provided, and test the resulting executable on > your own platform, along with also verifying that the package meets > the requirements of the ASF policy on releases - > http://www.apache.org/legal/release-policy.html#management > > In particular, you should (at least) follow these steps. > > 1. Download the artefact to be voted on and unzip it. > 2. Check that the artefact does not contain any jar files (there are > branding folders with the name *.jar). > 3. Verify the cryptographic signatures, the NOTICE and LICENSE file > 4. Build it using the README provided by the artefact. > 5. Look in nbbuild/netbeans for the NetBeans installation created by > the build process and try running it. > > In addition to checking the sources, you may check the associated > convenience binary zip, installers, nbms and maven staging at the links > above. You are not expected to check every convenience binary. > > As well as checking any artefact functions correctly, you > should check that it has been correctly signed by a PMC member, and > that the source being voted on is sufficient to build the relevant > binary. > > This vote is going to be open at least 72 hours, vote with +1, 0, and > -1 as usual. (Please justify -1) > > Please mark your vote as binding only if you're an Apache NetBeans > PMC member to help with voting admin. > > Only respond if you are going to vote - this is NOT a discussion thread. > > Apache NetBeans 20 will be released if and when this vote passes. > > --- > > Voting template > > Please copy and paste
Re: JPA Libraries: to bug report or not to bug report
Hi Stephen, Am Donnerstag, dem 23.11.2023 um 21:10 + schrieb Stephen Parry: > *We already use Maven* , with the correct dependencies - but the wizard only > lists the JPA 3.0 support if there is a suitable library available on the > Tools Libraries screen. please have a look here: https://github.com/apache/netbeans/pull/6748 I understand, that your use-case are not JavaEE/JakartaEE applications, but standalone applications. For these the change enhances the persistence provider selection to not only support bundled/legacy libraries, but also libraries on the classpath. The latter covers maven dependencies. Please see if that fixes your use-case. A test build is available from the checks page of the PR: https://github.com/apache/netbeans/actions/runs/6984884741 or directly: https://github.com/apache/netbeans/suites/18481345427/artifacts/1072745346 Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: /src/it/java and /src/it/resources support
Hi Alex, Am Donnerstag, dem 23.11.2023 um 23:43 +0300 schrieb Alex Orlov: > As I understand nobody reads NB github discussions so I will ask here. Could > anyone say — why NB doesn’t support /src/it/java and /src/it/resources > folders for integration tests and their resources? > There is such issue https://issues.apache.org/jira/browse/NETBEANS-2470 but > it seems to be obsolete. Should it be reopened in github issue tracker or > there is no chance that it will be fixed. two reasons jump to my mind: 1. You can have unittests and integration tests in src/test/java. At least last time I checked surefire and failsafe supported that. 2. Nobody cared enough to fix it, you might want to tackle it. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: JPA Libraries: to bug report or not to bug report
Hi Stephen, Am Donnerstag, dem 23.11.2023 um 00:09 + schrieb Stephen G. Parry: > > 1. There are no JPA 3.1 libraries in the Libraries list. Without a > suitable entry in the list, JPA 3.1 does not appear as an option in the > wizards, e.g. the Persistence Unit wizard. The project dependencies seem > to have no effect on this. This can be worked around by creating a new > library entry yourself and adding the jakarta persistence API, > EclipseLink and Jakarta Activation API, plus javadocs and sources. This > is a fiddly process. my advice: teach your students how to include the right dependencies from maven. A minimal pom.xml should be doable and opens options for the future. You can open an issue about this, but if you don't fix it yourself there is a pretty high likelyhood, that no one else will do it. > 2. If you do add the library entry, The new API is 'unlocked', but is > incorrectly identified in the dropdown of the persistence unit wizard as > EclipseLink (JPA 3.0) You mean it should be JPA 3.0+? I have some doubts that the wizard create anything that is not compatible wiht 3.0 and 3.1. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: NetBeans 20 Release Candidate 2 - Project Properties Not Opening
Hi Josh, Am Freitag, dem 27.10.2023 um 22:20 -0500 schrieb Josh Juneau: > I have been testing NetBeans 20 RC2 and it looks like the "Project > Properties" dialog is not opening, as expected. Typically when > right-clicking on a project and selecting "Properties" from the contextual > menu, the "Properties" dialog should open. Unfortunately it is not working > with RC2. > > I also tested with NetBeans 20 RC1 and "Project Properties" did open > without issues. could you please check if this: https://github.com/apache/netbeans/issues/6622 matches your problem (it sounds so). Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[RESULT][VOTE] Release lib.profiler natives version 1-24aefa9
Hi all, thank you all for taking time to check the release and vote. The vote is closed now and succeeded with 5 binding +1 votes: Antonio Vieiro (https://people.apache.org/phonebook.html?uid=vieiro) Eric Barboni (https://people.apache.org/phonebook.html?uid=skygo) Michael Bien (https://people.apache.org/phonebook.html?uid=mbien) Neil C Smith (https://people.apache.org/phonebook.html?uid=neilcsmith) Matthias Bläsing (https://people.apache.org/phonebook.html?uid=matthiasblaesing) Will now move artifacts to release folder. Greetings Matthias Am Dienstag, dem 10.10.2023 um 20:57 +0200 schrieb Matthias Bläsing: > 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
[RESULT][VOTE] Release dlight.nativeexecution natives version 1-24aefa9
Hi all, thank you all for taking time to check the release and vote. The vote is closed now and succeeded with 5 binding +1 votes: Antonio Vieiro (https://people.apache.org/phonebook.html?uid=vieiro) Eric Barboni (https://people.apache.org/phonebook.html?uid=skygo) Michael Bien (https://people.apache.org/phonebook.html?uid=mbien) Neil C Smith (https://people.apache.org/phonebook.html?uid=neilcsmith) Matthias Bläsing (https://people.apache.org/phonebook.html?uid=matthiasblaesing) Will now move artifacts to release folder. Greetings Matthias Am Dienstag, dem 10.10.2023 um 20:57 +0200 schrieb Matthias Bläsing: > 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-24aefa9
+1 (binding) Am Dienstag, dem 10.10.2023 um 20:57 +0200 schrieb Matthias Bläsing: > 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) Am Dienstag, dem 10.10.2023 um 20:57 +0200 schrieb Matthias Bläsing: > 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: Issue with Netbeans, for school project
Hi, Am Donnerstag, dem 12.10.2023 um 09:24 + schrieb STEVENS, Alexander (astev200): > > Hi I pressed the hotkey of ‘Shift + F11’ to ‘clean’ the project (I > was doing this to resolve another problem) although now I have run > into another problem. > When I run the project, this message pops up. > this mailinglist strips images, so please resend with text in the mail, not an image. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[VOTE] Release dlight.nativeexecution natives version 1-24aefa9
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
[VOTE] Release lib.profiler natives version 1-24aefa9
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
Re: [DISCUSS] Native binary handling (or, does NetBeans have a future on macOS?)
Hi Neil, Am Mittwoch, dem 04.10.2023 um 20:44 +0100 schrieb Neil C Smith: > If the vote doesn't pass then someone else will need to do the > various PRs (I'm tied up most of next week), or we delay freeze, or > we have another release without Apple Silicon support? I'm willing to give releasing the native artifacts a try. So would you be willing to close the first set of votes? Then I would call a vote on: 1-24aefa99e4f366699431e3e85e6b1127e966a151 That is the release, that holds the merge of the modified built. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Native binary handling (or, does NetBeans have a future on macOS?)
Hi, so being constructive about this, I put this together: https://github.com/apache/netbeans/pull/6539 I think my concerns are addressed by that. Greetings Matthias Am Mittwoch, dem 04.10.2023 um 20:44 +0100 schrieb Neil C Smith: > On Wed, 4 Oct 2023, 20:07 Matthias Bläsing, > wrote: > > > I was asked to reply here: > > > > I'm irritated, that votes are called for packages, that violate Apache > > Release requirements (at least to my understanding). > > > > I will not vote on dlight.nativeexecution as I assume the reaction will > > also be just a shrug. The question that remains: Why call a vote then? > > > > So we can host the binaries on dist.a.o rather than the far worse shadow > releasing via OSUOSL that was used for the last update. > > I'm sorry you're irritated by this, but understand it. I made a judgement > call to keep the binary artefact contents the same for this first trial. > This causes a minor violation of the release policy on convenience > binaries, I realise, even though not really public facing. I wish I'd > realised that earlier! It is still far less of one than putting them on > OSUOSL in my opinion. It is at least a step in the right direction. > > The actual voting artefact (source) is compliant, if the contents are a > little odd at present. Again, it was a judgement call to try this with the > workflow without changing too much in the module itself. > > Both things need addressing in the NB21 cycle if this works for us. It's on > my to-do list already leading on from this. > > If the vote doesn't pass then someone else will need to do the various PRs > (I'm tied up most of next week), or we delay freeze, or we have another > release without Apple Silicon support? > > I'm a little irritated with myself for not foreseeing this problem. > Hindsight is great, sorry! > > 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: website migration to antora
Hi, Am Montag, dem 02.10.2023 um 10:56 +0200 schrieb Eric Barboni: > > 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). > I don't understand why this question was asked if the result does not matter? The work is underway, so I assume, it is already decided (how?). At least the multiple already created repositories to me indicate this. Questions that might have been raised: - What is the real problem with the current build? - Which other static CMS systems were evaluated? - Why is antora better than the other systems and better than the current build? Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Native binary handling (or, does NetBeans have a future on macOS?)
Hi, I was asked to reply here: I'm irritated, that votes are called for packages, that violate Apache Release requirements (at least to my understanding). I will not vote on dlight.nativeexecution as I assume the reaction will also be just a shrug. The question that remains: Why call a vote then? Greetings Matthias Am Mittwoch, dem 27.09.2023 um 11:54 +0100 schrieb Neil C Smith: > Hi, > > The lack of native binaries supporting Apple Silicon (eg. profiler and > terminal) is becoming more and more of an issue, and costing us users. > I assume that is something we wish to address?! And incidentally, > while we're at it, if you're a NetBeans PMC member or committer using > it on macOS regularly on either Apple silicon or x86_64, your input > and testing through this would be very appreciated. I've got access > to an M1 machine myself, but it's not what I use day-to-day. > > We have a PR updating the build scripts for the profiler binaries at > https://github.com/apache/netbeans/pull/6494 I think we have > something for the terminal support somewhere too, although it might > need a little work. > > In some ways, that's the easy part - we need a better way to handle > releasing these for consumption in the main IDE build. > > The Windows launchers are currently in a separate repository, and > released via Maven central - > https://github.com/apache/netbeans-native-launchers We could use a > similar approach. However, that might be more difficult for a > cross-OS range of binaries (and with the profiler header generation)? > > We have a GitHub workflow file for building profiler binaries already > at > https://github.com/apache/netbeans/blob/master/.github/workflows/native-binary-build-lib.profiler.yml > That has the benefit of cross-OS building, including for macOS where > we don't have an ASF Jenkins option currently. > > The workflow appears to be missing a source bundle that we could use > for voting purposes, but could be adapted to generate that in an > initial stage (we don't want the full NetBeans sources!). We could > then look to release the binaries via dist.apache.org for consumption > in IDE builds? > > Given there is not a huge amount of time before freeze for NB20, we > could perhaps look to only update the binaries for macOS at this time, > moving to ASF builds of the rest for NB21? > > Thoughts? > > Best wishes, > > Neil > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [VOTE] Release lib.profiler natives version 1-r2196e46
-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. I have a minimal nitpick about the source zip. It seems overly complicated. It took me a some time to realise, that only the profiler/lib.profiler/native/ is relevant and can be diffed against the corresponding repository dir. The rest of the file is a placeholder directory structure, which looks like it could be replace by "mkdir -p $DEST" in the build scripts. Greetings Matthias Am Dienstag, dem 03.10.2023 um 10:51 +0100 schrieb Neil C Smith: > 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. > > Primary voting artefact : > https://dist.apache.org/repos/dist/dev/netbeans/native/netbeans-profiler/1-r2196e46/profiler-external-sources-1-r2196e46.zip > SHA : > 6f41f0bed161f2e718bf1f0497e631446bf363d7b6affd4ab021e12a5b94c88b8896da8d6c7ec6bd5f411b64770276379c394041f120fe62edd52ed72e2ba3b0 > > Alongside the source artefact are the zipped binary artefacts : > > https://dist.apache.org/repos/dist/dev/netbeans/native/netbeans-profiler/1-r2196e46/ > > 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 > > The source and binary artefacts were created in GitHub actions run > https://github.com/apache/netbeans/actions/runs/6351527745 using the > workflow at > https://github.com/apache/netbeans/actions/runs/6351527745/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, > > Neil > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [VOTE] Release Apache NetBeans 19
Am Dienstag, dem 29.08.2023 um 10:45 +0100 schrieb Neil C Smith: > -- 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 Ubuntu OpenJDK 17 on Ubuntu 23.04 > [X] I have tested the binary zip with Ubuntu OpenJDK 17 on Ubuntu 23.04 > [X] I have tested the DEB installer(s) with Ubuntu OpenJDK 17 on Ubuntu 23.04 > [ ] I have tested the Maven artefacts > [ ] I have tested the VSCode extension - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Plugin Verifikation Plugins Portal (changing rules)
Hi again, I just noticed, that the LDIF Editor and LDAP Explorer plugins were rejected for the plugin portal for 19. Reasoning: Plugin unsigned. Please sign (self-signed is ok) and re-submit for verification This was not a problem in: 11, 12, 16 and 17. _Nothing_ changed for these plugins and I don't see why I should was resources in CI/CD systems and on maven central, just to "fix" something, that was not broken for a long time. The requirement to sign the plugins is questionable in itself without a trust anchor or revocation list, but I can live with with requiring signature for updates (this will become fun, once the signature expires, but ...), but this is not the case here. For the PlantUML Plugin I created a signed build, because the package changed and so it was worth spending the bandwith and space and time. Would be nice, if you could take back the reject and get this approved. Thank you 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
Unstable Build-Tools Test: I'm looking into it
Hi all, it seems the new test I introduced into the maven module fails randomly. I'm looking into it. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [VOTE] Release Apache NetBeans parent pom 4
+1 (binding) Looks good to me. Am Mittwoch, dem 05.07.2023 um 16:18 +0200 schrieb Eric Barboni: > Dear members of Apache NetBeans community. > > I want to call a vote on releasing Apache NetBeans parent pom 4. This is a > technical artefact. > > This is a maven pom containing basic information needed like mailing > list,license for our others artefacts. > > Changes from v3: > use apache parent pom 30(was 26) > > The voted artefacts sources are located here: > https://dist.apache.org/repos/dist/dev/netbeans/netbeans-parent/netbeans-par > ent-4 > > In addition to that, Maven artifacts built from > https://github.com/apache/netbeans-parent with the commit id > 90f823e499fc0ecf00d8605d2760cd883679a570 (tag netbeans-parent-4) are staged > in the following repository: > https://repository.apache.org/content/repositories/orgapachenetbeans-1130/ > > sha512 is: > bce3886bf4afc3d0ac5803a7bce76877c1ea184d112f5b5cfb7e913ae56e9261ae273c2a8f02 > 5d6b0a8b362feeff65a6af5992482c5ea8b0d3fd190779462f4c > > 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: Validation of `taglib.xml` files in `web.jsf.editor` module
Hi Benjamin, Am Montag, dem 03.07.2023 um 20:01 +0800 schrieb Benjamin Asbach: > During the work on the support I wanted to extend this part to support > jakarta namespaces: > > https://github.com/apache/netbeans/blob/2edeaf99fc099b754b234600dbc491f0449659b0/enterprise/web.jsf.editor/src/org/netbeans/modules/web/jsf/editor/facelets/mojarra/ConfigManager.java#L1062-L1153 > > Basically it parses `tablib.xml` files and this part seems to try to > validate that xml via a schema based on the version of the `taglib.xml`. > > But while debugging I could not find a scenario where > `builder.isValidating()` is returning `true`. > > Does anybody know more on this part of the code? Can it be removed? > Should it get fixed somehow so that the schema is validated? having a quick look at this I read it like this: The DocumentBuilder that is use dto parse the taglib comes from mojara itself, which in turn uses a default instance. So the builder you get and its configuration is outside your control. I assume, that at some point in time, schemas and URLs were taken seriously and at that point it might have been a validating parser. Maybe the developers of NetBeans implemented the support in that timeframe. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Syntaxhighlighting with textmate for a new language
Hi Oliver, Am Mittwoch, dem 28.06.2023 um 20:34 +0200 schrieb Oliver Rettig: > > I have implemented a simple netbeans plugin for my .ocga-files: > > https://github.com/orat/netbeans-ocga > > The files are correctly recognized, the registered icon is shown in the file- > nodes. > > The textmate file is found but in the editor nothing happens. No syntax- > highlighing is shown. Also newstart of the ide has no effect. > > The textmate-file works fine in visual-studio. > > Any ideas what can be wrong? I doubt, that the grammar file is found. The maven project structure is incorrect. Maven expects, that in the src/main/java directory only java files are found. Everything else is ignored. Runtime resources (the grammar file is such a resource), that are to be packed into the final jar need to be in the src/main/resources folder. This differs from antlr where the grammar file is used at compile time and not used at runtime and thus does not need to be packaged. TL;DR: Move src/main/java/de/orat/math/netbeans/ocga/ocga.tmLanguage.json to src/main/resources/de/orat/math/netbeans/ocga/ocga.tmLanguage.json and it works. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Posts with invalid "From" dev@netbeans.apache.org
Hi, as a notice: I just rejected a message posted to this mailinglist. The "From" was set to dev@netbeans.apache.org, which is obviously incorrect. As there was also no name given in the message I did not clear it for sending. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: applemenu model Error
Hi Eric, I saw this problem in the past when building with an inconsistent set of JDK. I.e. my build JDK was JDK 11 and the value of the property nbjdk.home pointing to JDK 8 (or the other way round). This was solved by removing the nbjdk.home property (beware, you can have it configured in different places) and thus building with a single JDK. There can be no general problem build NetBeans, see the battery of build ran on every PR and also the fact, that we successfully released NB18, which requires voters to build the project from source. HTH Matthias Am Freitag, dem 16.06.2023 um 16:47 -0500 schrieb Eric Bresie: > Cloned from master > ant -q clean > ant -Dcluster.config=full build > During which I get the below error. > > I am not on an Apple device so even if this is some form of "applemenu" for > apple platforms, I'm not sure why when I'm on a Windows platform? > > Is there something necessary to include the "java.awt.desktop" (module) in > the build somewhere (i.e., enable a module of some type)? Where might that > get set? > > -do-compile: > [nb-javac] Compiling 7 source files to > C:\git\netbeans\platform\applemenu\build\classes >[repeat] warning: [path] bad path element > "C:\git\netbeans\platform\applemenu\build\desktop-classes-classes": no such > file or directory >[repeat] warning: A file for type > 'org.netbeans.modules.applemenu.Bundle' already exists on the sourcepath or > classpath >[FAILURES in applemenu] > > BUILD FAILED > C:\git\netbeans\nbbuild\build.xml:635: The following error occurred while > executing this line: > C:\git\netbeans\nbbuild\build.xml:630: The following error occurred while > executing this line: > C:\git\netbeans\nbbuild\build.xml:665: The following error occurred while > executing this line: > C:\git\netbeans\nbbuild\build.xml:648: The following error occurred while > executing this line: > C:\git\netbeans\nbbuild\build.xml:630: The following error occurred while > executing this line: > C:\git\netbeans\nbbuild\build.xml:665: The following error occurred while > executing this line: > C:\git\netbeans\nbbuild\build.xml:648: The following error occurred while > executing this line: > C:\git\netbeans\nbbuild\build.xml:630: The following error occurred while > executing this line: > C:\git\netbeans\nbbuild\build.xml:677: The following error occurred while > executing this line: > C:\git\netbeans\nbbuild\templates\common.xml:207: Compile failed; see the > compiler error output for details. > > Total time: 15 seconds > > > Eric Bresie > ebre...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [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 distribution JDK 17 on Ubuntu 23.04 (required) [X] I have tested the binary zip with distribution JDK 17 on Ubuntu 23.04 [X] I have tested the EXE installer(s) with Amazon Corretto 17 on Windows [X] I have tested the DEB installer(s) with distribution JDK 17 on Ubuntu 23.04 [ ] I have tested the Maven artefacts [ ] I have tested the VSCode extension Additional info (optional) - any specifics on what you've tested - Loaded Java projects and Angular project - Noticed ConcurrentModificationExceptions in Angular project (separate discussion), code completion still works - On windows I had to manually override the JDK detection using javahome parameter in installer as Java is not installed, but unzipped -- Am Dienstag, dem 23.05.2023 um 16:00 +0100 schrieb Neil C Smith: > This is our first voting candidate for the release of Apache NetBeans 18. > > 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 18 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/18/ > > They were built by the Jenkins pipeline : > > https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/release180/18/ > > > > We are primarily voting on : > > https://dist.apache.org/repos/dist/dev/netbeans/netbeans/18/netbeans-18-source.zip > > SHA512 : > a3b846abf6b78b501840d7b78912eddebd6dbfe7c451d71a77dadab01231ef331f1caa198af0805e70f304e98e40e72ca5811aa78999c67383105c6d31abc1f5 > > 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/18/ > > Binaries associated with the source - netbeans-18-bin.zip as well as > update content under the nbms folder. > > -- at https://dist.apache.org/repos/dist/dev/netbeans/netbeans-installers/18/ > > 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. > 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/18.0/ > > The VSCode extension signed by a PMC member using binaries created > during the build process. > > > > Maven Artefacts > > The Maven artefacts for Apache NetBeans 18 are ready on staging > associated to this vote. > > https://repository.apache.org/content/repositories/orgapachenetbeans-1129/ > > The version is : RELEASE180 > > > > 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 18 will be released if and when this
Re: [DISCUSS] Release Apache NetBeans 18: ConcurrentModificationException from javascript scanning
Hi, Am Mittwoch, dem 24.05.2023 um 08:51 -0700 schrieb dev@netbeans.apache.org: > I'd proceed as is, document that on the release notes. If there would be > many complaints, I might consider to do a 18u1 nbm release. oh nameless one, want to say who you are? But in general I agree. > On 5/24/23 01:25, Neil C Smith wrote: > > On Tue, 23 May 2023 at 20:20, Matthias Bläsing > > wrote: > > > testing the voting candidate, I noticed, that the JS scanning can run > > > into a ConcurrentModificationException. > > ... > > > For me this is not a big problem as described above, but people using > > > plain JS in the IDE might face bigger problems. At least the message > > > log gets flooded and of of course you'll get annoying exception > > > bubbles. > > > > > > Sorry about that. > > That's fine! It happens. But this is a discussion thread, so what > > exactly are we discussing? How do you think we should proceed? I wanted to make people aware. If noone cares in the Vote, then it is not a problem. Now at least noone can say "Oh, that is surprising, damn...". > > I'm also concerned why this hasn't been picked up during the release > > candidate phase? Those are cheap to produce, voting candidates are > > not. In particular now we've moved to a consolidated vote. Are there > > things we could improve in our RC testing? Voting candidates should > > not need to be tested for functionality. 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. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[DISCUSS] Release Apache NetBeans 18: ConcurrentModificationException from javascript scanning
Hi all,
testing the voting candidate, I noticed, that the JS scanning can run
into a ConcurrentModificationException. The issue will cause an
exception to be raised when scanning a construct like this:
export class test {
field1 = "Value1";
method1() {
}
}
I did not catch this earlier as I'm running with a private plugin that
excludes node_modules folder from JS scanning and did insufficient
testing when integrating the fix, that enabled accessing members from
"export class" constructs.
A fix is here:
https://github.com/apache/netbeans/pull/5983
It applies the pattern that is used in other places, where the property
copy code is invoked.
For me this is not a big problem as described above, but people using
plain JS in the IDE might face bigger problems. At least the message
log gets flooded and of of course you'll get annoying exception
bubbles.
Sorry about that.
Matthias
-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: plugin portal submission inquiry
Hi, the plugin as verified, but not yet approved for the plugin portal. As the request looked sane to me, I approved the plugin and it is not present. @Jiří if that was not correct, I apologize @Donald: Please don't include apache infra in requests for NetBeans specifics. They care for the base infrastructure, but the Projects have to handle their specifics Greetings Matthias Am Sonntag, dem 14.05.2023 um 21:53 + schrieb Brutzman, Donald (Don) (CIV): > Well, we got an optimistic reply from Webmaster early Friday 12 May > but we still have not seen the plugin from within NetBeans. Also not > sure what to do with the offered catalog.xml.gz (which does not have > any reference to x3d-edit or x3dedit within it). > > Meanwhile the plugin portal says something different: update 4.0.28 > is verified, but not approved. > > Wondering if there is synchronization or deployment problem? If > there is anything for us, we are happy to support next steps. > > TIA for all support. > > > Hello plugin owner, > > this is to inform you that publishing of your plugin on the Plugin > Portal Update Center was approved. > > Plugin: X3D-Edit > NetBeans version: 17 > Verification status: GO > > Your plugin should be already available on the Plugin Portal Update > Center by now: > > https://plugins.netbeans.apache.org/data/17/catalog.xml.gz > > Thanks for your contribution! > NetBeans development team > > P.S.: This is an automatic email. DO NOT REPLY to this email. > > > all the best, Don > -- > Don Brutzman Naval Postgraduate School, Code USW/Br > brutz...@nps.edu > Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA > +1.831.656.2149 > X3D graphics, virtual worlds, navy robotics > https://faculty.nps.edu/brutzman > > From: Geertjan Wielenga > Sent: Sunday, May 7, 2023 4:12 AM > To: Brutzman, Donald (Don) (CIV) > Cc: Jiří Kovalský ; Norbraten, Terry (CIV) > ; dev ; > infrastruct...@apache.org > Subject: Re: plugin portal submission inquiry > > I think just submit the plugin again, should be fine. > > Gj > > On Sat, 6 May 2023 at 19:45, Brutzman, Donald (Don) (CIV) > wrote: > > Geertjan, thanks for the nudge. After many years and much work > > using the X3D-Edit plugin, we are quite excited to finally “step > > up” to mainstream NetBeans. > > > > We will be happy to continue improving our plugin configuration to > > match best practices. Thanks in advance for all feedback > > > > all the best, Don > > -- > > Don Brutzman Naval Postgraduate School, Code USW/Br > > brutz...@nps.edu > > Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA > > +1.831.656.2149 > > X3D graphics, virtual worlds, navy robotics > > https://faculty.nps.edu/brutzman > > > > From: Geertjan Wielenga > > Sent: Friday, May 5, 2023 11:12 AM > > To: Brutzman, Donald (Don) (CIV) ; Jiří Kovalský > > ; dev > > Cc: Norbraten, Terry (CIV) ; > > infrastruct...@apache.org > > Subject: Re: plugin portal submission inquiry > > > > Jiri, > > > > Can you advise? > > > > Gj > > > > On Fri, 5 May 2023 at 20:09, Brutzman, Donald (Don) (CIV) > > wrote: > > > Hello. Terry Norbraten and I are trying to see if his submission > > > for review of a corrected Apache NetBeans plugin was received. > > > > > > * https://plugins.netbeans.apache.org/catalogue/?id=88 (version > > > 4.0.27) > > > > > > We got feedback on not having a self-signed signature – he added > > > that and resubmitted a correction (version 4.0.28) earlier this > > > week. Unfortunately we can’t tell if it was received. > > > > > > Please advise how we can be sure a change was received. Tracking > > > status and answering any emergent questions would be nice too… > > > > > > p.s. I tried to get a password for Confluence, but did not > > > receive the renewal message that was promised. > > > > > > Thanks in advance of all help. > > > > > > all the best, Don > > > -- > > > Don Brutzman Naval Postgraduate School, Code USW/Br > > > brutz...@nps.edu > > > Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA > > > +1.831.656.2149 > > > X3D graphics, virtual worlds, navy robotics > > > https://faculty.nps.edu/brutzman > > >
Re: Indexing, Lucene?
Hi, first, the basic idea, that underlies alls lucene data is still the same: You create a "document", add key-value pairs to it and let the indexer do its magic. When it is done, you can query the index. Yes we need to move to a newer version of lucene in the core indexer and it is a problem, that the module exposed lucene internals and some queries will be hard to adapt, but it is IMHO doable. For normal queries and usage the Parsing and Indexing API IMHO works. I think CSS indexer might be approachable, although it carries additional complexity cause it handles embedding into HTML. - The indexer is in css.editor and implemented in org.netbeans.modules.css.indexing.CssIndexer. It is created by an embedded factory, which is registered in the layer file in Editors/text/css. - CssIndexer#index is called by the Parsing and Indexing infrastructure for each recognized document and when the parsing result is available - the #index method extracts the IDs, classes, html elements and clors from the CSS parser and stores that in the documet - The document is then stored using the Indexing Support If you now want to now where inside the project a certain CSS class is used, you use the convenience function findClasses in org.netbeans.modules.css.indexing.api.CssIndex. This method builds the query and dispatches it to the QuerySupport. It will return the FileObjects, that hold the corresponding classes. There are dark parts in the API, but the basic usage is ok. HTH Matthias Am Samstag, dem 13.05.2023 um 17:14 -0700 schrieb Laszlo Kishalmi: > Dear all, > > Does anyone have a good knowledge on our Indexing API? > > I would like to add some search functionality to my HCL/Terraform support. > > I do not know too much of Lucene, but what I know is not really match > with what I see there. Then I checked and we are using Lucene 3.6.2, > that is more than 10 years old by now. > > I've also checked what would it mean to upgrade that to a recent > version. It seems to be a hard job to take, moving even to Lucene 4.x > would be hard, at least with my level of knowledge. (Lucene changed > completely between 3.x to 4.x) > > I've seen that the new Maven Indexer comes with Lucene 9.x. So we have > recent Library support. > > My first question, shall we start to do something about the old Lucene? > > Shall I invest using our current indexing API? > What I'm leaning for at the moment is, to move the Lucene 9.x library > out of Maven Indexer as a separate library project then I'd implement my > things using Lucene 9 directly. > > What do you think on 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: Plugins Portal Issue
Hi, Am Freitag, dem 12.05.2023 um 19:01 +0200 schrieb Albilu: > I think there is still a couple of issues related to the version. > 1. The version displayed in netbeans is 0 This is correct. Have a look at your plugins info.xml: OpenIDE-Module-Specification-Version="0" What you expect is: OpenIDE-Module-Implementation-Version="RELEASE170-1.0" This is not what drives autoupdates. > 2. The Author name is missing in the UI even thought i have it > filled in the pom and My Plugins -> Authors No - you assigned your user accout to the plugin (default), but your user accout does not have a real name. Most probably you configured github to hide your name. In consequence it is not present for the plugin portal to use. Greetings Matthias PS: I'm not the end-user support for the plugin portal and don't want to be mailed directly - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Plugins Portal Issue
Hi again, thank you. Indeed there was an issue in the db structure, which caused the version string not fitting into the DB column. This is fixed now. Please try again. Greetings Matthias Am Samstag, dem 29.04.2023 um 17:52 +0200 schrieb Albilu: > > > io.github.albilu > python > RELEASE170-1.0 > > > https://repo1.maven.org/maven2/io/github/albilu/python/maven-metadata.xml > > Le 29/04/2023 à 17:35, Matthias Bläsing a écrit : > > Hi, > > > > thank you for the data, could you also give the maven coordinates for > > the plugin (groupId and artifactId?). > > > > Thank you > > > > Matthias > > > > Am Samstag, dem 29.04.2023 um 16:47 +0200 schrieb Albilu: > > > > > > Le 29/04/2023 à 11:37, Matthias Bläsing a écrit : > > > > > > > > > > > Hi Albilu, > > > > > > > > please provide the full message and stack trace. The screenshot is > > > > cut of. > > > > > > > > Greetings > > > > > > > > Matthias > > > > > > > > > > > > Am Samstag, dem 29.04.2023 um 10:44 +0200 schrieb Albilu: > > > > > > > > > When adding a new plugin and clicking Save Plugin in the Plugin > > > > > Portal i am getting this. Please have a look > > > > > > > > - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Plugins Portal Issue
Hi, thank you for the data, could you also give the maven coordinates for the plugin (groupId and artifactId?). Thank you Matthias Am Samstag, dem 29.04.2023 um 16:47 +0200 schrieb Albilu: > > > Le 29/04/2023 à 11:37, Matthias Bläsing a écrit : > > > > > Hi Albilu, > > > > please provide the full message and stack trace. The screenshot is > > cut of. > > > > Greetings > > > > Matthias > > > > > > Am Samstag, dem 29.04.2023 um 10:44 +0200 schrieb Albilu: > > > > > When adding a new plugin and clicking Save Plugin in the Plugin > > > Portal i am getting this. Please have a look > > > > > > - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Plugins Portal Issue
Hi Albilu, please provide the full message and stack trace. The screenshot is cut of. Greetings Matthias Am Samstag, dem 29.04.2023 um 10:44 +0200 schrieb Albilu: > When adding a new plugin and clicking Save Plugin in the Plugin > Portal i am getting this. Please have a look >
Re: [Plugin Portal] Is Plugin Portal broken?
Hi Junichi, hi Michael, > On 27.04.23 06:58, Junichi Yamamoto wrote: >> Errors are shown in PP now... >> Could anyone please have a look at it? the issue is fixed. There was a storage problem and the Apache VMs came up with readonly filesystem. As I could not sudo anymore, I contacted Apache infra via the slack channel and it was immediately fixed. Am Donnerstag, dem 27.04.2023 um 20:17 +0200 schrieb Michael Bien: > this is currently causing CI to fail since a test is downloading nbms > from there. > https://github.com/apache/netbeans/actions/runs/4820687838/jobs/8586082259 > > would be good to check if the tests can download the nbm form maven > central instead, since all plugins should be there too. I would not rely on that. For me that is an implementation details, that nobody should depend on. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [NetBeans PluginPortal] Check your plugin with the new Apache NetBeans 18!
Hi, Am Freitag, dem 21.04.2023 um 14:03 -0700 schrieb Ernie Rael: > On the plugin "version management" page "NB 18" is listed, > but there is no "Request verification" button for that release. please check the box before "NB 18" and save. Then you can request verification. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] disable remote index extraction by default [NB18]
Hi, Am Dienstag, dem 18.04.2023 um 07:48 +0200 schrieb Jan Lahoda: > I apologize for being contrarian, but since the index download > started for me (again) while on a bus with very poor internet > connection, I guess I should tell you my view. no reason to apologize. > Unless I am mistaken, the index gz has currently roughly 1.9GB, and > it tooks several minutes to actually create the Lucene index from it, > consuming some more space and CPU. > > To be honest, it never seemed very polite to me to download and > process so much without asking. > > I guess alternatives that I would see would include (combination of > options possible): > - explicitly ask before downloading (possibly allowing the user to > select auto-download) Yes, if people get notified, that they'll get the full index locally, then I'm okk with that. I see a problem if features silently give outdated answers or don't work at all. Else we'll get "NetBeans suggested version X, but Y is already on central, why is this not current?". > - have the features that use the index do some query on a server, if > there isn't a downloaded index (or if it is stale/obsolete) IMHO this highly depends on the speed of the API. If the latency is high, the next bug will be "It takes ages until my POM tells me, that it is outdated". > - given that https://github.com/apache/netbeans/pull/4999 produces a > smaller index, we could have a download location (server) at least > for maven central that would serve this optimized index. If I > understand it properly, the smallest index under that PR is 0.8GB, > and if it would compress reasonably well, it might be (say) 0.5GB > compressed - much better than 1.9GB, and no significant CPU usage > after the index is downloaded. (Even if it was 0.8GB, it is still > much better than 1.9GB+CPU churn.) Truncating the index needs to be done carefully. NetBeans has a search my SHA1 (or MD5?) feature. That will break, if you remove that data from the index. A similar situation will arise, if arbitrary cut offs are done based on time. Consider a libary, that does some interesting algorithm, that just works the same even after years. If we cut the index at 6 months for example, that artifact won't be found anymore. > There was also an argument on conserving the ASF resources in another > discussion recently. If I consider there would be (only) 10 000 > installations of NetBeans, with the default setting to download the > index once a week, it is almost 20TB of data every week if I count > correctly. +the CPU cycles to convert the index on user's machines. > It seems there may be a way to conserve the ASF resources and provide > better experience to the users at the same time. The download is from sonatypes CDN. Given that they actively discourage central mirrors, I have not to much concern here. It is also the the resourced of the ASF. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-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.18 netbeans-platform-app-archetype 1.23
+1 (binding) - checksums and signature match - contents of voting artifacts matches repository - LICENSE and NOTICE files look sane - checked the contents of the voting artifacts - they look sane Am Mittwoch, dem 12.04.2023 um 20:48 +0200 schrieb Eric Barboni: > Dear members of Apache NetBeans community. > > I want to call a vote on releasing the following Apache NetBeans Archetypes > > 1) nbm-archetype-1.18 > 2) netbeans-platform-app-archetype-1.23 > > 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/nb > m-archetype/nbm-archetype-1.18/ > 2) > https://dist.apache.org/repos/dist/dev/netbeans/netbeans-maven-archetypes/ne > tbeans-platform-app-archetype/netbeans-platform-app-archetype-1.23/ > > The source are respectivly located (repository, commit id, tag) > 1) https://github.com/apache/netbeans-mavenutils-archetype-nbm-archetype > with > the commit id 9a8d62568a939e1b1a97ee01106eb18cf50c3bcc (tag > nbm-archetype-1.18) > 2) > https://github.com/apache/netbeans-mavenutils-archetype-netbeans-platform-ap > p-archetype with > the commit id e9c50b3fd8bb446e827fb38a4e26b31676643897 (tag > netbeans-platform-app-archetype-1.23) > > Archetypes are staged in the following maven repository > https://repository.apache.org/content/repositories/orgapachenetbeans-1126/ > > 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: [DISCUSS] disable remote index extraction by default [NB18]
Hi, I don't think this is a good idea. If your disc is to small to hold the maven index there is a pretty good chance, that your setup is often broken. Quite frankly at work I never noticed NetBeans downloading the index, it is lost in the noice of normal operation. We will basicly loose all advantages of maven indexing. My local repository does not hold the latested artifact (rendering the corresponding hint useless) and completion is interesting because I did not yet use the artifact. Else I most probably have the right setup for the setup already at hand. The option to disable is now there. Given that part of the discussion around JDK 11 baseline was to make a faster maven indexer available gives this another bad taste. So from my POV this should not be done. Greetings Matthias Am Donnerstag, dem 13.04.2023 um 18:47 +0200 schrieb Michael Bien: > Hello devs, > > NB 18 will split the indexer setting into two check boxes, one for local > indexing, one for remote index extraction, > > see screenshot: https://github.com/apache/netbeans/pull/5646 > > I propose to disable remote index extraction by default, until we solved > some more of the issues at least. > > main complains are: > > - failing extraction when temp folder is too small e.g #5815 (NB 18 > will deactivate indexing on extraction failure) > > - extraction takes too long e.g #5809 > > Local index scanning scans your .m2 repo, which is fast and might be > sufficient for many use cases and therefore a better default for now. > > thoughts? > > -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 > > > - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-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] Minimum JDK build and run policy (dropping JDK 8)
+1 (binding) Am Dienstag, dem 11.04.2023 um 09:16 +0100 schrieb Neil C Smith: > # Proposed policy > > * Apache NetBeans 18 will be the last release to support running the > platform on JDK 8. > > * From Apache NetBeans 19, the minimum JDK required to build and run > the IDE or platform will be JDK 11. > > * Future releases will take an "LTS-1" strategy for building and > running (and CI testing) of the IDE and platform. Three JDKs will be > supported at any one time - the current JDK, plus the previous two LTS > releases. eg. NetBeans 20 and 21 (Nov 2023 / Feb 2024) will support > JDK 11, 17 and 21. NetBeans 22 (May 2024) will support JDK 17, 21 and > 22. > > ## Background > > The Apache NetBeans IDE has officially required JDK 11 to build and > run since NetBeans 13 in March 2022. The platform (and unofficially > the IDE) have continued to support running on JDK 8 - all modules > requiring a higher JDK must currently be optional. Various tests have > continued on JDK 8. > > This situation is causing issues as workarounds must be found for > currently non-optional features that have dependencies or other > requirements for running on a higher JDK (eg. Maven indexing / Lucene > [1]). It's causing delays, complications and missed testing time in > integration of new features (eg. problems merging support for EE 10 > [2]). Supporting an increasing range of JDKs is causing increasing > workload, both for people and CI. Meeting the challenges of deprecated > (for removal) features in the JDK is also complicated by the > additional JDK requirements. > > ## Notes > > * Apache NetBeans users will continue to be recommended to use the > current or latest LTS JDK to run the IDE. The IDE will continue to > support users developing projects for/with JDK 8, for as long as > nb-javac and other dependencies allow. > > * This proposal specifically doesn't address when the default bytecode > level across the codebase is increased. This can happen when required, > but non-optional modules would be free to adopt the minimum JDK as > they need to. > > * Optional modules may continue to require a runtime JDK higher than > the minimum. Should it become necessary, build time optional modules > might be considered - eg. a build on the minimum JDK may exclude > modules that will not run on that JDK at runtime. > > * Some modules that are of independent use (eg. lookup, utilities, > etc.) might be nominated and advertised to continue JDK 8 support for > the time being. This is not expected to cover the runtime container as > a whole - https://netbeans.apache.org/tutorials/nbm-runtime-container.html > > * Once NetBeans 19 is released, the NetBeans 18 release branch could > be used to backport and release JDK 8 supporting fixes, subject to any > PMC members wanting to manage those releases. > > * The term "platform" is used in reference to the whole framework of > modules that we release (eg. via Maven), not just the platform > cluster. > > [1] https://github.com/apache/netbeans/pull/4999 > [2] https://github.com/apache/netbeans/pull/4692 > > > ## Procedure > > This vote is going to be open at least 72 hours. Vote with +1, 0, and -1. > > Please mark your vote as binding only if you're an Apache NetBeans PMC > member to help with voting admin. > > Decision will be by majority vote, with at least 3 binding positive votes. > > Thanks, > > Neil > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
Hi, Am Dienstag, dem 11.04.2023 um 11:27 + schrieb Glenn Holmer: > My hope is that the JDK8 gang will see > the error of their ways and come back to the fold after losing the vote. please lets stay civil here. I think it is clear, that there is disagreement, but that does not mean, that one of the groups is better or worse. I think that both camps "JDK 8 should stay" and "JDK 8 is dead" have their points and I also think that the difference is mostly in the weighing of the arguments and drawing conlusions from that. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: AW: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
Hi, Am Montag, dem 10.04.2023 um 13:02 +0200 schrieb Geertjan Wielenga: > My feeling on this discussion is that, yes, it’s unfortunate that we’re > getting to fruitful discussion only at this late stage — but better late > than never and without this useful thread we wouldn’t have been getting > where we’re getting at all. > > Could one way forward be to do a Zoom call with all those invested in this > (and then bring everything decided back to this mailing list) during the > coming week, unless we can already predict that that will not bring us > further. I see no basis for a discussion. There are two people saying, that they would help with working on JDK 8 support, but that does not answer how people not wanting to stay in the past shall be included. Lets stay with the example already establieshed: maven indexer. I was so fed up with this dicussion, that I did the prototype, not the two people that advocated JDK 8 support is a good idea. So why should I expect this to get better in the future? Given that "#4795 Use frgaal compiler to compile NetBeans" was reopend. I have a serious WTF moment. I'm denied access to modern API, but the author wants a backporting compiler? All this accomplishes is getting us further away, from what is Java in my mind. I verifies concerns that were raised by others for previous PRs. At some point NetBeans was cool from me, because it did not reinvent the wheel (Swing vs. SWT). Reality makes me reconsider this. What I'm missing to the "API stability" and "Compatibility" axis is the sustanibilty axis. Seriously arguing for using older, most probably unmaintained libraries will not fly with me. Lucene as one such example is a beast and learning it once is enough, learning it twice, once for serious interest and once for NetBeans JDK 8 support is useless (for me). And the "let then run NetBeans in degraded mode on JDK 8" idea won't fly, because it will cause strage issue, which are not triaged by the JDK 8 interested people. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [Lazy Consensus] Minimum JDK build and run policy (dropping JDK 8)
+1 Am Montag, dem 03.04.2023 um 10:38 +0100 schrieb Neil C Smith: > As mentioned elsewhere, I'm kicking off a process to bring this issue > to a decision. For various reasons, having a decision before we > branch off NB18 is desirable. I've drawn up a draft proposal (below) > that tries to encompass most of what has been expressed, and hopefully > achieves that - thanks to those who have already given feedback in its > iteration. > > This thread will be active for 7 days. Expressions of support and > disagreement welcomed. In particular, if you -1 please offer an > alternative to all or part of this proposal that you're able to help > implement. We should try and reach a consensus position that removes > any block. If after the 7 days we cannot do this, then we move to a > vote on this with any agreed amendments. > > See also the page at > https://community.apache.org/committers/consensusBuilding.html > > Thanks, Neil > > > > # Proposed policy > > * Apache NetBeans 18 will be the last release to support running the > platform on JDK 8. > > * From Apache NetBeans 19, the minimum JDK required to build and run > the IDE or platform will be JDK 11. > > * Future releases will take an "LTS-1" strategy for building and > running (and CI testing) of the IDE and platform. Three JDKs will be > supported at any one time - the current JDK, plus the previous two LTS > releases. eg. NetBeans 20 and 21 (Nov 2023 / Feb 2024) will support > JDK 11, 17 and 21. NetBeans 22 (May 2024) will support JDK 17, 21 and > 22. > > ## Background > > The Apache NetBeans IDE has officially required JDK 11 to build and > run since NetBeans 13 in March 2022. The platform (and unofficially > the IDE) have continued to support running on JDK 8 - all modules > requiring a higher JDK must currently be optional. Various tests have > continued on JDK 8. > > This situation is causing issues as workarounds must be found for > currently non-optional features that have dependencies or other > requirements for running on a higher JDK (eg. Maven indexing / Lucene > [1]). It's causing delays, complications and missed testing time in > integration of new features (eg. problems merging support for EE 10 > [2]). Supporting an increasing range of JDKs is causing increasing > workload, both for people and CI. Meeting the challenges of deprecated > (for removal) features in the JDK is also complicated by the > additional JDK requirements. > > ## Notes > > * Apache NetBeans users will continue to be recommended to use the > current or latest LTS JDK to run the IDE. The IDE will continue to > support users developing projects for/with JDK 8, for as long as > nb-javac and other dependencies allow. > > * This proposal specifically doesn't address when the default bytecode > level across the codebase is increased. This can happen when required, > but non-optional modules would be free to adopt the minimum JDK as > they need to. > > * Optional modules may continue to require a runtime JDK higher than > the minimum. Should it become necessary, build time optional modules > might be considered - eg. a build on the minimum JDK may exclude > modules that will not run on that JDK at runtime. > > * Some modules that are of independent use (eg. lookup, utilities, > etc.) might be nominated and advertised to continue JDK 8 support for > the time being. This is not expected to cover the runtime container as > a whole - https://netbeans.apache.org/tutorials/nbm-runtime-container.html > > * Once NetBeans 19 is released, the NetBeans 18 release branch could > be used to backport and release JDK 8 supporting fixes, subject to any > PMC members wanting to manage those releases. > > * The term "platform" is used in reference to the whole framework of > modules that we release (eg. via Maven), not just the platform > cluster. > > [1] https://github.com/apache/netbeans/pull/4999 > [2] https://github.com/apache/netbeans/pull/4692 > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Hi Jaroslav, Am Sonntag, dem 02.04.2023 um 15:38 +0200 schrieb Jaroslav Tulach: > > It also becomes increasingly difficult to > > motivate myself to fix JDK 8 issues in my freetime. > > I can imagine that. However we are not coding NetBeans to please ourselves, > but to please our users. These users won't benefit from developers leaving NetBeans development, because they don't want to code for the past. That is the other side of the coin. At least I'm pondering if that might be a good idea. > NetBeans Platform users need JDK8 support. That's why > I am volunteering to maintain and run the CI & tests on JDK8. Which Platform users need JDK 8 support and why can't they just stay on (for example) NetBeans 17? They are obviously not interested in features, as they are already cut of from all developments in the JDK area and thus I question why they would be interested in NB features. What is more these users will have the same problem with other libraries, which are also dropping support for old JDKs. Fixing CI & tests is only part of the problem (which is already enough), but our dependencies also can't be updated because of this and that is a massive problem. To give a different perspective: Running software on JDK 8 at my work is a sign of problems and is faced with serious questions from OPs. Even JDK 11 is beginning to becoming increasingly questionable and quite frankly, once you over the JDK 8 barrier, it gets better. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Reformat the code base
Hi Jeremy, Am Mittwoch, dem 29.03.2023 um 12:57 + schrieb Jeremy Cavanagh: > But, I have now reached a point where I have some problems that I cannot find > a solution for and need your help/guidance. > > First, a few of the packages (17 of 114) in platform give me the error > message "cannot find item" and in some cases they are in the same package? > > Secondly, I cannot compile anything and therefore cannot test anything. I get > the error message: > > ant -f /Users/jeremycavanagh/netbeans-jc-cleaned/platform/api.io > -Djavac.includes=org/netbeans/api/io/Fold.java compile-single > init-tasks: > /Users/jeremycavanagh/netbeans-jc-cleaned/nbbuild/default.xml:31: taskdef > class org.netbeans.nbbuild.JNLPUpdateManifestStartup cannot be found > using the classloader AntClassLoader[] > BUILD FAILED (total time: 0 seconds) > > I can only assume that my setup is incorrect for dealing with the NetBeans > source. I am using the source download for NB13 and have not changed anything > other than Java files. when I work on NetBeans the first thing I do: Clean the branch I choose as basis and do a build of the full IDE. Then I work on the individual modules. I suspect, that in your case you never build the nbbuild project, which defines the class you are missing. If you don't want to build the whole codebase, you can try if running "ant bootstrap" from the base directoy is enough to fix your issue. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: log4j
Hi, Am Freitag, dem 24.03.2023 um 22:29 +0100 schrieb Matthias Bläsing: > Hi, > > to prevent duplicate work: I'm preparing a patch to get log4j out. > > Greetings and here it is: https://github.com/apache/netbeans/pull/5716 a nightly build is available from the checks summary page: https://github.com/apache/netbeans/actions/runs/4519593120 or directly via: https://github.com/apache/netbeans/suites/11806181515/artifacts/616280546 Two tests are relevant: a) @William: is your security happy with this? b) @all: does see anyone see problems? (Unittests ran and were green). Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: log4j
Hi, to prevent duplicate work: I'm preparing a patch to get log4j out. Greetings Matthias Am Donnerstag, dem 23.03.2023 um 09:53 -0400 schrieb William Shackleford: > Netbeans appears to include log4j even the most recent version. > > in > > netbeans/ide/modules/ext/log4j-1.2.15.jar > > Our IT security group has flagged it and requires that it be removed even > though as it is version 1 it is not vulnerable to the most famous issue as > apparently there were other issues and it is no longer supported. > > What are the consequences of removing it? > > How would I go about committing or just suggestion a change to have it > removed from future versions to avoid triggering our security team from > telling everyone to delete it and maybe all of netbeans with 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
Re: log4j
Hi, Am Freitag, dem 24.03.2023 um 01:59 + schrieb Eirik Bakke: > Is there any reason to use log4j instead of java.util.logging these > days? If log4j is only use in one place in the NetBeans codebase, it > might be beneficial to get rid of it in any case--one less > dependency, and fewer overlapping logging libraries. sure, but the usage is only in the codebase by proxy. The html parser and validator are 90% (or more) external code. That code uses log4j. You have to look into the code that is used to build the external binaries for these two components to see the impact of log4j. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: log4j
Hi, Am Donnerstag, dem 23.03.2023 um 09:53 -0400 schrieb William Shackleford: > Netbeans appears to include log4j even the most recent version. > > in > > netbeans/ide/modules/ext/log4j-1.2.15.jar > > Our IT security group has flagged it and requires that it be removed even > though as it is version 1 it is not vulnerable to the most famous issue as > apparently there were other issues and it is no longer supported. > > What are the consequences of removing it? If I saw it correctly, log4j is used by the html validator only. Anything that calls into that might break. That also might happen indirectly. > > How would I go about committing or just suggestion a change to have it > removed from future versions Have a look at the html.parser and html.validator modules. Both most probably need to be updated or might be patched not to carry log4j. Patching html.validator might be the quickest way, updates to current version might be better in the long run. The hard > to avoid triggering our security team from > telling everyone to delete it and maybe all of netbeans with it? The alternative is: Solve organisational problems inside the organisation. If the security team indeed has the misconception that "has log4j === is vulnerable", than you might need a new security team. My status on the CVEs: - CVE-2019-17571: SocketServer needs to be explicitly loaded, we are not vulnerable - CVE-2020-9488: We don't use the SMTPAppender, we are not vulnerable - CVE-2021-4104: We don't use the JMSAppender, we are not vulnerabe - CVE-2022-23302: We don't use the JMSSink, we are not vulnerable - CVE-2022-23305: We don't use the JDBCAppender, we are not vulnerable - CVE-2022-23307: Apache Chainsaw is not used Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Heads up: Reintegration of UPL/BSD/MIT licenses JS files tests + graaljs parser
Hi all, I want to call attention on this PR: https://github.com/apache/netbeans/pull/5694 This PR reintegrates code, that was externalized as part of the donation process. This work was triggered because I had to regenerate golden files, that were part of the external files bundle and thus made it difficult to work with. My reading of the license policies allows code with UPL, MIT or BSD license to be incorporated into the project. This changes reduces the number of binary downloads from the OSUOSL hosting and makes it easier to work with the code. It would be great to have some more eyes on this. For comments please prefer the github comment function for the PR. Thank you Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))
Hi Neil, Am Donnerstag, dem 16.03.2023 um 11:23 + schrieb Neil C Smith: > Hi Matthias, > > On Sun, 12 Feb 2023 at 22:22, Neil C Smith wrote: > > On Sun, 12 Feb 2023, 19:11 Matthias Bläsing, > > wrote: > > > > > > Hi, > > > > > > Am Freitag, dem 10.02.2023 um 10:12 + schrieb Neil C Smith: > > > > On Thu, 9 Feb 2023 at 19:02, Matthias Bläsing > > > > wrote: > > > > > - commit to make NetBeans runnable on JDK LTS -1 > > > > > - build with JDK LTS -1 > > > > > - be able to be build with the current JDK > > > > > > > > +1 as long as that includes the platform. > > > > > > > > That is what I suggested in the other thread (I don't see why we need > > > > multiple threads incidentally!) > > > > > > > > An LTS-1 strategy seems closest to how NetBeans used to function - > > > > major-1, in a time when it also had more development resources? > > > > > > > > Let's also be clear, though, that adopting an LTS-1 strategy means > > > > dropping JDK 11 support either in our first release after JDK 21, or > > > > the first after JDK 22 - so latest May 2024. > > > > > > why would we do that? I said _runnable_ and _buildable_. As long as the > > > current JDK support the target release I did not exclude that. > > > > > > In which case I don't understand what you mean by committing to make > > NetBeans buildable and runnable on LTS-1? That to me means dropping the > > commitment to JDK 11 when it becomes LTS-2. > > I'd still really like to see us make some movement here before the > next release freeze in a month. > > I'd still like to understand whether we're saying the same or > different things about adopting an LTS-1 strategy here? what I think I wanted to say is, that we don't need to raise the bytecode level for the whole codebase and could keep most modules on language level 8, but give developers the option to raise it to LTS-1 if necessary. The definition of necessary might be a matter of dicussion. This would give people who aim for compatibility with JDK 8 for some modules the handle to work with NetBeans and get their wishes. External dependencies might cause us to be required to raise the Java level over LTS - 1. Some libraries might evolve faster than we like and we might not be able to work with the LTS - 1 compatbile version. This then also means, that the build JDK would be required to be current or current-1. I think generally aiming for compatibilty with LTS - 1 would be a good compromise. Greetings Matthias, not sure if this really helped to clear things 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: allowing snapshot maven artefacts during build
Hi Eric, Am Mittwoch, dem 15.03.2023 um 18:58 +0100 schrieb Eric Barboni: > > [Temporary use non maven dependencies for external dependencies] > > Or maybe we already have this. > Actually we have a partial solution. Have a look here: https://github.com/apache/netbeans/blob/master/extide/gradle/external/binaries-list For some unknown reason gradle does not distribute the distribution zip via maven central and so we need to download it directly. You can't work around the checksum, but the build system tells you what it would expect, and what it calculated, so you can trivially find the right checksum by doing a priming build. HTH Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [Discuss] Security and lunching programs from the IDE
Hi, Am Dienstag, dem 14.03.2023 um 18:31 +0100 schrieb Antonio: > > 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? > for the building invocation it is IMHO a no-brainer. Nobody expects the shell to ask you "Do you really want to invoke 'make' from the path?" and from my POV it is the same for the IDE. If a command is on the PATH of the user, the user installed it. If a user is intelligent to write/install a programm "kill my disk" and name it "cargo" and make it available on the PATH, then this is evolution and not a problem of the IDE. So TL;DR: Invoking cargo without asking the user explicitly is IMHO fine. We ask for trust when opening gradle projects, because _parsing_ gradle projects requires invoking foreign code, which could be surprising. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: heads up: Rust not properly squashed to master
Hi Antonio, Am Montag, dem 06.03.2023 um 20:05 +0100 schrieb Antonio: > 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. I think what we see is just an unsquashed merge. I come to this conclusion because I compared with my local branch, which I used to propose additional changes: 5fa12d488bbc112fd3bea66b1cb809788e01e750 my fourth proposed change is in both branches 41696a67e9e047dc9c5e281dc5a61d850b82beb6 fixes a problem I introduced fb0c60b52ab7dcd114b43c34ab155e9b1768de1e adds rust tests to CI/CD f09ba6dae8568240fc289fc926b98de4c8f48adc is merge commit There is no indication for unrelated changes. > Do we revert those commits in master? The rust addition could look nicer, but it is the reviewed state and the individual commits also look ok. 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. Matthias, Who yesterday realized, that he is fixing issues he introduced himself - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-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, Am Sonntag, dem 26.02.2023 um 20:30 +0100 schrieb Michael Bien: > b) we merge to master right away, but we will have to add rust to a > cluster config which is essentially release+rust and use this config for CI we can build with "-Dcluster-config=full" for CI/CD. That way all modules are build and test can be run. The merge to master needs some more work in this PR IMHO as it for example contains a ZIP with example code, which is a no-go (we explicitly ask committers to verify, that no JAR is present in the source code and the same should be true for ZIPs). Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Uploading binaries (OSUOSL)
Hi Eric. Am Sonntag, dem 26.02.2023 um 08:35 -0600 schrieb Eric Bresie: > Out of curiosity and for reference, why are these files published there? > > Do I remember correctly that these are there to provide access to download > for use in the build for files not available on other sources, have been > abandoned/no longer available for some reason, or some other reason? more or less. Take the PHP files as an example they are derived from the PHP installation and are provided for efficient access. The same is true for the W3C documentation for CSS properties. > Assume some portion of these may be available for other sources (i.e. maven > central). Is any of these sources available as an alternative? Sure - many and without having counted the majority is already downloaded from Maven Central. We can't use "any" source, it also needs to be reliable. For Maven Central all is good, but others might raise more questions. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [External] : No communication from plugin portal verifiers (do we need to drop plugin portal?)
Hi Jiří, Am Freitag, dem 17.02.2023 um 18:49 +0100 schrieb Jiří Kovalský: > Anyway, I can give the context here. :) About two months ago Mani > (Cc:ed here) joined the team of plugin verifiers as a new volunteer and > during the introductory call with him we talked about whether plugins > should be signed. As per the Plugin Verification specification [1] the > installation instructions only mention: > > 1.8 If validation warning about self-signed certificate is displayed, > accept it by clicking Continue button. > > [1] > https://synergy.netbeans.apache.org/#/title/verification_of_apache_netbeans_plugin/ > > It says nothing about not signed plugins but we came to the conclusion > that if self-signed plugins are explicitly tolerated then not-signed one > should not. > > However, if you and Neil think that the signature check should be > excluded completely and NetBeans community supports it, let's remove it. > And even more if the whole verification process is seen as useless then > let's have an official community voting and then get rid of it! I have mixed feeling about this, but my surprise did not come from the requirement to sign the package, but from the change in policy. If the plugin had not been approved multiple time before, I might have just shrugged if off, this way it felt very irritating. Anyway, I want to focus on other things, so for now lets keep it as is. Seems to be working. > As an immediate fix I have changed my NoGo to Go for all your 3 plugins > and hereby ask Carlos/Geertjan/Mani to do the same if they agree. Thank you. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-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) [X] binding (member of PMC) My vote is based on [X] I have built and tested the source with Ubuntu OpenJDK 11 on Ubuntu 22.10 [X] I have tested the binary zip with Amazon Corretto 17.0.4.1+9-LTS on Ubuntu 22.10 [X] I have tested the DEB installer(s) with Ubuntu OpenJDK 11 (default-jdk) on Ubuntu 22.04 [ ] I have tested the Maven artefacts [ ] I have tested the VSCode extension Additionally checked, that ZIP file contents and repository contents matched (as far as can be expected). The DEB installer worked nicely and is well integrated into gnome-shell (icon, naming). Nice! - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
No communication from plugin portal verifiers (do we need to drop plugin portal?)
Hi again, this is getting ridiculous. There are zero replies here (apart from telling me things I already now) and no verifiers reacts. I'm currently thinking, that we need a different approach to the Plugin Portal, as there is zero communication. This is the place authors are pointed and here they don't get an anwser. There is still no statement why my plugins suddenly get rejected, although they were fine for multiple releases. Greetings Matthias Am Montag, dem 30.01.2023 um 19:03 +0100 schrieb Matthias Bläsing: > Hi, > > I asked for reverification of three plugins. These plugins: > > - PlantUML-NB > - LDIF Editor > - LDAP Explorer > > are verified for NB 11.0/12.0 till NB 16 version. Nothing was changed > on the plugins for 17 and now the plugins are not good enough anymore. > So what is going on? > > They are rejected, because they are not signed, fine, but then why is > that an issue? The signatures gain you nothing as there is no trust > anchor, we don't distribute blocked author certificates and the > download from plugin portal is protected by the checksums. > > This is bogus, so what changed and why was this not communicated? I > assume, that I was not the only one suprised by this. What is more, I'd > need to do a full release cycle without any code changes, without any > benefit. > > Greetings > > Matthias > > PS: Jiří I added you to direct CC as I'm not sure how closely you > monitor dev@ > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-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: Fedora 37 + RedHat JDK 17 + NB 17 vc1 doesn't start
Hi Michael, Am Donnerstag, dem 16.02.2023 um 17:52 +0100 schrieb Michael Bien: > tested the rpm on Red_Hat-17.0.5.0.8-1.fc37 > (+Red_Hat-17.0.6.0.10-1.fc37) and it did not start, it did work fine on > other JDKs, e.g on Corretto 17: > > [mbien@fedora netbeans-validation]$ uname -a > Linux fedora 6.0.10-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Nov 26 > 16:55:13 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux > [mbien@fedora netbeans-validation]$ java -version > openjdk version "17.0.5" 2022-10-18 > OpenJDK Runtime Environment (Red_Hat-17.0.5.0.8-1.fc37) (build 17.0.5+8) > OpenJDK 64-Bit Server VM (Red_Hat-17.0.5.0.8-1.fc37) (build 17.0.5+8, > mixed mode, sharing) > > [mbien@fedora netbeans-validation]$ netbeans > which: no javac in > (/home/mbien/.local/bin:/home/mbien/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin) > WARNING: package com.apple.eio not in java.desktop > java.lang.UnsatisfiedLinkError: Can't load library: > /usr/lib/jvm/java-17-openjdk-17.0.5.0.8-1.fc37.x86_64/lib/libawt_xawt.so > at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2393) > at java.base/java.lang.Runtime.load0(Runtime.java:755) > at java.base/java.lang.System.load(System.java:1953) Neil is right. I checked the Fedora 37 workstation live DVD and: sudo dnf list installed | grep jdk shows: java-17-openjdk-headless.x86_64 This is trivially fixed by running: sudo dnf install java-17-openjdk And yay - starts. HTH Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: HELP!!! java.sql not showing in Project/Libraries/JDK node and Configuration Settings
Hi Sean,
Am Mittwoch, dem 15.02.2023 um 11:00 -0600 schrieb Sean Carrick:
> I've been trying to explain to a guy regarding the java.sql module
> use in NetBeans projects and am having trouble getting him to
> understand what I'm saying. I could really use some help with this.
> He is stuck on the fact that, even though the java.sql module is
> present in the Java Platforms dialog, he is not seeing listed under
> the Libraries/JDK node in the Projects window. Also, he is not able
> to use Fix Imports to bring in the import statements for the SQL API
> classes in his Code Editor.
You did not specify the project type. I'll assume it is an ant project
with type "Java Modular Project". By default a modular project only has
access to java.base. To extend this a module-info.java file in the
default package has to be created. Sample:
module newmodule {
requires java.sql;
}
Here I declare, that my module is named newmodule and depends on
java.sql. NetBeans recognises this and "magically" makes the classes
available.
HTH
Matthias
-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: 17 blocker? — [apache/netbeans] no library found for namespace http://omnifaces.org/ui (Issue #4976)
Hi, Am Mittwoch, dem 15.02.2023 um 10:21 +0100 schrieb Geertjan Wielenga: > OK, let’s prioritize for the next release and note as a known error to be > fixed ASAP since it blocks all usage of Java/Jakarta EE. this needs people adding support for the jackarta namespace. This might or might not be hard. We need to see. I don't see this as a release blocker. The reason is, that Oracle dropped development of JavaEE and transfered the source code to the Eclipse Foundation. Instead of doing the right thing: Donate the naming rights to them to, they did the insane thing: They donated the source code, but required the implementations to switch package names and XSD namespaces. This is wrong on so many levels.On that day a lot of cute kittens died an gruesome death. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Hi,
Am Montag, dem 13.02.2023 um 20:25 +0100 schrieb Jaroslav Tulach:
> I am voting against dropping support for JDK 8.
I don't understand you: JDK 8 is a dead end. There will be no new
features. So why do you expect new features from your libraries? Just
use lookup/collections/whatever from ${last nb version compatible with
$ancient toolchain} and be done with it.
You would also to expect people to keep writing Windows 95 compatible
applications just because you refuse to update.
The question is: How long do you expect us to stay in the past?
> At any vote you ever call - even if I miss it. Please be so nice and make
> sure
> I know that a vote is about to happen. Otherwise I will challenge that vote
> at
> Apache authorities.
What do you expect them to do? A vote is called, there is a voting
period and later it is counted. This follows the procedures declared by
Apache. The only thing such a thread causes for me, to ensure, that hte
rules are literally followed.
> Why not? It is a machine doing the testing and it runs "for free".
Lie. Of course someone has to pay for the computing power and you might
not have noticed, but we already had to shift from travis to github
actions. Surely not because travis continued to provide the services
for free.
Greetings
Matthias
-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))
Hi, Am Freitag, dem 10.02.2023 um 10:12 + schrieb Neil C Smith: > On Thu, 9 Feb 2023 at 19:02, Matthias Bläsing > wrote: > > - commit to make NetBeans runnable on JDK LTS -1 > > - build with JDK LTS -1 > > - be able to be build with the current JDK > > +1 as long as that includes the platform. > > That is what I suggested in the other thread (I don't see why we need > multiple threads incidentally!) > > An LTS-1 strategy seems closest to how NetBeans used to function - > major-1, in a time when it also had more development resources? > > Let's also be clear, though, that adopting an LTS-1 strategy means > dropping JDK 11 support either in our first release after JDK 21, or > the first after JDK 22 - so latest May 2024. why would we do that? I said _runnable_ and _buildable_. As long as the current JDK support the target release I did not exclude that. > > - keep as many modules as feasible compatible with release 8 > > -1 : A number of things have come up recently about preparing for JDK > 21+ that would involve increasing the bytecode level and APIs in some > core parts of the NetBeans runtime container. Could you elaborate what that is? Not using Thread#stop and dropping finalizers is it not. That can be done (with some pain) with support for 8. So what is the problem? > We could choose to keep release 8 for some modules that make sense as > libraries outside of the runtime container - utilities, lookup, etc.? > But surely it makes more sense to explicitly specify those, so that we > and third-parties have clarity over which things still support JDK 8? This might be part of a constructive counter proposal of the "JDK 8 will never die" fraction. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Rust, anyone?
Hi, Am Samstag, dem 11.02.2023 um 15:54 +0100 schrieb Antonio: > > 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? I think it would be fine as a core plugin. We have C support and Rust is not only the cool kid right now, it also seems to be there to stay (linux Kernel, Firefox, Chrome). Of course we need to shed the "it can't be removed" attitude I sometimes see here, but that should be doable. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: building netbeans w/ different compiler
Hi Brad,
Am Samstag, dem 04.02.2023 um 18:02 -0600 schrieb Brad Walker:
> On Sat, Feb 4, 2023 at 4:43 PM Matthias Bläsing
> wrote:
>
> > > 1 - Does compiling Netbeans out of the box continue to Java 8 as the
> > > compiler?
> >
> > You'll need JDK 11. Most modules still build for 8, but they use the
> > javac release flag to do that. I don't remember when that change was
> > made, but it was some time ago.
> >
> I see the following in platform/o.n.bootstrap/build.xml:
>
>
>
> depends="check-main-status,projectized-common.compile,rebuild-main"/>
>
>
> srcfile="${src.dir}/org/netbeans/Main.java"
> targetfile="${build.classes.dir}/org/netbeans/Main.class"/>
>
>
>
>
>
> debug="${build.compiler.debug}" debuglevel="${build.compiler.debuglevel}"
> deprecation="${build.compiler.deprecation}"
> optimize="${build.compiler.optimize}" source="1.8" target="1.8"
> includeantruntime="false">
>
>
>
>
>
>
No, that is just a hook into the "compile" ant task. What I mean is:
Default values for javac.source and javac.target:
https://github.com/apache/netbeans/blob/master/nbbuild/templates/common.xml#L68-L70
Definition of javac:
https://github.com/apache/netbeans/blob/master/nbbuild/templates/projectized.xml#L84-L87
Logic that maps target to release:
https://github.com/apache/netbeans/blob/master/nbbuild/antsrc/org/netbeans/nbbuild/CustomJavac.java#L68-L100
The overriding of the javac.source and target is actively used in the
java.disco module:
https://github.com/apache/netbeans/tree/master/java/java.disco
https://github.com/apache/netbeans/blob/master/java/java.disco/nbproject/project.properties#L22-L23
HTH
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
Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))
Hi, from my POV it is a fact, that NetBeans (the IDE) can't be required to be runnable on JDK 8 and in fact it is not. So my idea: - commit to make NetBeans runnable on JDK LTS -1 - build with JDK LTS -1 - be able to be build with the current JDK - allow modules to depend on libraries, that require newer JDKs (see new JakarataEE developments for example, OpenJFX) - keep as many modules as feasible compatible with release 8 - if a module needs to break compatibility with java 8 it is the job of people wanting it to stay compatible to do the necessary work - the more to the core, the better the arguments for breaking compatibitly should be The idea here is, that I see Jaroslavs point that libraries should be compatible and I'm willing to sacrifice syntactic sugar for compatibility. What I won't accept is that we are stuck in the past. OpenJFX has a webbrowser and thus quickly becomes a security component, we must be able to update this. This also introduces a baseline java version: The absolute lowest support java version is the one still supported by the most current JDK. Greetings Matthias Am Dienstag, dem 10.01.2023 um 15:16 +0100 schrieb Michael Bien: > Hello devs, > > I hope everyone recovered from the last JDK 8 thread and is ready for > the first JDK 8 thread of 2023 :) > > The commit validation job is currently testing on 8, 11, 17 and 20-ea. > It doesn't like NetBeans editor modules which require java 11 though > which blocks a Jakarta EE 10 PR atm (#4692). > > This means we need either 1) a volunteer who would like to spend time > and fix JDK 8 tests, 2) we remove JDK 8 from the CV test matrix or 3) we > won't be able to merge this pr before freeze. > > Given that NB doesn't really support running on JDK 11 since a while I > would simply opt for 2) and merge. > > The problem is that I don't know the NB VSCode Extension situation very > well. > > Have the NB VSCode Extension specific tests (which run on JDK 8) > sufficient coverage so that we can remove JDK 8 from the CV test matrix? > At what point will JDK 11 modules become a problem for VSCode? When will > the VSCode NB extension bump the runtime requirement to 11? > > The next modules which would require JDK 11 are probably maven related > (#4999) but this wouldn't be for NB 17. > > 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: Usage of DateTimeFormatter forbidden
Hi, Am Dienstag, dem 07.02.2023 um 20:59 +0300 schrieb name name2: > Hello > > https://github.com/apache/netbeans/pull/5445 > > SDT deprecated by fact of existing new java.time > SDT isnt thread safe and required ThreadLocal. The most part of code is > 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. SimpleDateFormat is perfectly fine when you deal with java.util.Date. The formatter is also save if only accessed from a single thread. I would agree to switch if you'd need to introduce a ThreadLocal, but there is no evidence to suggest this. So i agree, that the referenced PR introduces noice without much benefit. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: proposal for finalize() removed
Hi Brad,
Am Sonntag, dem 05.02.2023 um 12:07 -0600 schrieb Brad Walker:
> #finalize is deprecated
>
> To flag these places, I'm proposing to use the @Deprecated annotation
> tag
> in our code like the following:
>
> *ide/editor.lib/src/org/netbeans/editor/MarkBlock.java*
>
> /** Destroy the marks if necessary */
> @Deprecated(since="9", forRemoval=true)
> protected void finalize() throws Throwable {
> destroyMarks();
> super.finalize();
> }
what is the intention of this change? #finalize is called by the JDK
and not by user code. The javac already reports overrides of #finalize
as warnings, if you compile against a JDK that actually has the
deprecation and if the warnings will be visible.
You can test this with your sample, change
ide/editor.lib/project.properties to hold:
javac.compilerargs=-Xlint:unchecked -Xmaxwarns 2000
javac.source=8
javac.target=11
Then you'll find:
/home/matthias/src/netbeans/ide/editor.lib/src/org/netbeans/editor/MarkBlock.java:555:
warning: [deprecation] finalize() in Object has been deprecated
protected void finalize() throws Throwable {
/home/matthias/src/netbeans/ide/editor.lib/src/org/netbeans/editor/MarkBlock.java:557:
warning: [deprecation] finalize() in Object has been deprecated
super.finalize();
It will not stand out inside the 600+ other warnings.
Greetings
Matthias
-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: building netbeans w/ different compiler
Hi Brad, Am Samstag, dem 04.02.2023 um 16:27 -0600 schrieb Brad Walker: > I can't figure out what options to use so that doing a build with Ant > compiles with a different compiler. I've looked all over the web page and > can't seem to find it there. > > So 2 questions: > > 1 - Does compiling Netbeans out of the box continue to Java 8 as the > compiler? You'll need JDK 11. Most modules still build for 8, but they use the javac release flag to do that. I don't remember when that change was made, but it was some time ago. > 2 - What option would I pass to Ant in order for it to use a different > compiler? Creating a file ".nbbuild.properties" in your home directory with the contents: nbjdk.home= should do it. Or you ensure, that that file das not exists/the property is not set and put your target JDK as first element onto $PATH and set $JAVA_HOME accordingly. HTH Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: master compile error
Hello Anonymous, Am Freitag, dem 03.02.2023 um 21:17 +0300 schrieb name name2: > What to do with these errors? > > After running ant on root *origin/master*: > > projectized-common.compile: > > *javafx-nbms:* >[genkey] Generating Key for netbeans-bundled >[genkey] *keytool error: java.security.KeyStoreException: Key protection > algorithm not found: java.security.UnrecoverableKeyException: Encrypt > Private Key failed: getSecretKey failed: Password is not ASCII* >[genkey] Generating 2а048 bit RSA key pair and self-signed certificate > (SHA256withRSA) with a validity of 90 days >[genkey] for: CN=Ant Group, OU=NetBeans, O=Apache.org, C=US > [nbmerge] Failed to build target: all-updatecenters Looking at the build script: https://github.com/apache/netbeans/blob/master/nb/updatecenters/build.xml#L35-L41 The path is here used as password. So I suspect you have non ascii characters in the path of your build directory. Greetings Matthias PS: If you fix your email client to provide sane values for your realname, people might be more inclined to read the emails. My minds SPAM detection algorithm sorts "name name2" into the category of SPAM. - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-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 Plugin Verification - Changing Rules - suddenly not good enough anymore
Hi,
yes, I know how I can sign JARs/NBMs, the point is: This was not
necessary for multiple NetBeans releases. I'm missing the explanation
why something, that was fine for at least 5, releases is now a problem.
That communication did not happen and was not discussed here.
Greetings
Matthias
Am Montag, dem 30.01.2023 um 17:00 -0300 schrieb Moacir da Roza:
> I believe they need to be signed with a key included on keystore
>
> *1-* Use java key tool:
>
> keytool -genkey -keyalg RSA -alias my-key-alias-key -keystore keystore.jks
> -validity 365
>
>
> *2-* Include on pom.xml
>
> org.apache.netbeans.utilities
> nbm-maven-plugin
> 4.7
> true
>
>
> ${netbeansInstalationPath} -->
> ${basedir}/keystore.jks
> ${keypass}
> my-key-alias-key
>
>
>
>
>
> Em seg., 30 de jan. de 2023 às 15:03, Matthias Bläsing
> escreveu:
>
> > Hi,
> >
> > I asked for reverification of three plugins. These plugins:
> >
> > - PlantUML-NB
> > - LDIF Editor
> > - LDAP Explorer
> >
> > are verified for NB 11.0/12.0 till NB 16 version. Nothing was changed
> > on the plugins for 17 and now the plugins are not good enough anymore.
> > So what is going on?
> >
> > They are rejected, because they are not signed, fine, but then why is
> > that an issue? The signatures gain you nothing as there is no trust
> > anchor, we don't distribute blocked author certificates and the
> > download from plugin portal is protected by the checksums.
> >
> > This is bogus, so what changed and why was this not communicated? I
> > assume, that I was not the only one suprised by this. What is more, I'd
> > need to do a full release cycle without any code changes, without any
> > benefit.
> >
> > Greetings
> >
> > Matthias
> >
> > PS: Jiří I added you to direct CC as I'm not sure how closely you
> > monitor dev@
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> > For additional commands, e-mail: dev-h...@netbeans.apache.org
> >
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >
> >
> >
> >
>
-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
NetBeans Plugin Verification - Changing Rules - suddenly not good enough anymore
Hi, I asked for reverification of three plugins. These plugins: - PlantUML-NB - LDIF Editor - LDAP Explorer are verified for NB 11.0/12.0 till NB 16 version. Nothing was changed on the plugins for 17 and now the plugins are not good enough anymore. So what is going on? They are rejected, because they are not signed, fine, but then why is that an issue? The signatures gain you nothing as there is no trust anchor, we don't distribute blocked author certificates and the download from plugin portal is protected by the checksums. This is bogus, so what changed and why was this not communicated? I assume, that I was not the only one suprised by this. What is more, I'd need to do a full release cycle without any code changes, without any benefit. Greetings Matthias PS: Jiří I added you to direct CC as I'm not sure how closely you monitor dev@ - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Plugin Portal: Map Apache NetBeans project roles to pp3 roles
Hi all, there were now multiple discussion about admin and verifier access to the plugin portal. To ease this, I have created this PR: https://github.com/apache/netbeans-tools/pull/60 It will basicly map the two Apache NetBeans project roles to roles in the plugin portal: PMC members will automatically gain admin access Committer members will automatically gain verifier access It should be remembered, that PMC membership implies committer access, so all PMC members can automatically act as verifiers. The members need to login with the Apache OAuth login system and are then granted the corresponding permissions on the fly. The option to register separater admin/reviewer permissions is retained and there is a difference between an automatically mapped verifier and an explicitly registered verifier: Only the latter will get email notifications. The automatically mapped reviewers need to access the list of open verifications via the "Verification requests" menu entry. I'd like opinions and/or reviews. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Maven/Gradle Netbean Builds [Re: JUnit 5 Generated Tests Warning/Error]
Hi, Am Samstag, dem 07.01.2023 um 10:25 -0600 schrieb Eric Bresie: > That is a bigger philosophical/paradigm change here. Are there any > longer term plans to migrate the Netbeans codebase build from ant to > something other (Maven or Gradle)? I have to ask: What problem do you try to fix? Sure when the build is converted to another build system the problems will magically go away. Except they don't. Gradle has its own set of WTF elements, the same is true for maven. There are three things missing before changes could be done: - arguments why it is benefical to switch - preparations to counter all possible "what ifs" - someone who takes up the fight and does the work What is IMHO not a solution is a half migration, creating a hybrid build using ant and gradle/maven. This was done by liferay and IMHO it is a failure (oh for fun they also did not use plain gradle, they patched their chosen gradle version...). Seriously: If you just want unittests, go with the existing solution. If the pain is to high, add support for Junit 5, and if you want a lifetime job, switch build systems. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [VOTE] Release Apache NetBeans 16-u1 (Gradle Update)
+1 (binding) - signatures and checksums match - contents of source zip match repository - LICENSE and NOTICE files look sane - building from source zip leads to a working IDE Thank you. Am Samstag, dem 24.12.2022 um 16:32 -0800 schrieb Laszlo Kishalmi: > This is our first voting candidate for the release of Apache NetBeans 16-u1. > > Please note all requirements below for validating sources and > convenience binaries (nbm-s) before voting. > > If the voting passes, the release binaries (nbm-s) would be distributed > directly on our NetBeans 16 Update Center. > There are no other binaries planned for this release. > > Apache NetBeans 16-u1 contains only two module updates: > > - org.netbeans.modules.gradle > - org.netbeans.modules.gradle.java > > The list of PR-s in this release above NetBeans 16: > > https://github.com/apache/netbeans/milestone/21?closed=1 > > > > Build artifacts are available here : > > https://dist.apache.org/repos/dist/dev/netbeans/netbeans/16-u1/ > > They were built by the Jenkins pipeline : > > https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/netbeans/job/release160/16/ > > There is an excerpt available on the modified update.xml, which would be > used to patch the NB 16 update center xml: > > https://dist.apache.org/repos/dist/dev/netbeans/netbeans/16-u1/nbms/updates.xml > > > > > Even though this is a patch release, we are primarily voting on : > > https://dist.apache.org/repos/dist/dev/netbeans/netbeans/16-u1/netbeans-16-u1-source.zip > > SHA512 : > 3502f86544ee50e54c6fcd07c45da01df6393bb8d5cfae7a02db314c51466ab66da993c43302d809aeff20f34d61929a69f628a70045dc773555fd640e97235a > > KEYS file : https://downloads.apache.org/netbeans/KEYS > > > > 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 artifact to be voted on and unzip it. > 2. Check that the artifact 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 artifact. > 5. Look in nbbuild/netbeans for the NetBeans installation created by the > build process and try running it. > > In addition to checking the sources, you should check the associated > convenience binary nbms by try to import them into an existing NetBeans > 16 IDE. > > Being a patch release, there would be *no separate voting* for the > convenience binaries (nbms). > > > This vote is going to be open at least 72 hours, vote with +1, 0, and > > -1 as usual. (Please justify -1) > > Please mark your vote with (binding) only if you're an Apache NetBeans > PMC member to help with voting admin. > > Only respond if you are going to vote, i.e., this is NOT a discussion > thread. > > Apache NetBeans 16-u1 will be released if and when this vote passes. > > Thank you to all contributors for all your hard work! > > Best wishes, > > Laszlo Kishalmi > > Neil, Eric thanks for the guidance! > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-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: Sending NB16 notice to plugin authors (was: Re: [PLUGINS][RELEASES] Preparation for NetBeans 16 plugins)
Hi, Am Samstag, dem 26.11.2022 um 06:42 +0100 schrieb Michael Bien: > was the mail supposed to reach all owners who registered a plugin? > > I only got a plugin verification mail so far. (i checked spam) yes - the mail setup of the system was broken and the mails bounced from some of the senders. It will be better next time. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [VOTE] Release Apache NetBeans 16
+1 (binding) - checksums look good (SHA512+GPG) - release zip matches repository - rat check runs clean - LICENSE and NOTICE files look sane - building from source creates a working IDE Am Montag, dem 21.11.2022 um 16:52 + schrieb Neil C Smith: > This is our first voting candidate for the release of Apache NetBeans 16. > > Please note all requirements below for validating sources and > convenience binaries before voting. > > Apache NetBeans 16 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/16/ > > They were built by the Jenkins pipeline : > > https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/netbeans/job/release160/11/ > > > > We are primarily voting on : > > https://dist.apache.org/repos/dist/dev/netbeans/netbeans/16/netbeans-16-source.zip > > SHA512 : > 6a329b87558e0841252b66b1364f1d45aaba7c1f8efa3b8c70c993fcf4e18c371828f86d5c28f127b8e776591e037f9b540a3e38c0aec48a413682fad6c24941 > > 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/16/ > > Binaries associated with the source - netbeans-16-bin.zip as well as > update content under the nbms folder. > > > > Maven Artefacts > > The Maven artefacts for Apache NetBeans 16 are ready on staging > associated to this vote. > > https://repository.apache.org/content/repositories/orgapachenetbeans-1122/ > > The version is : RELEASE160 > > > > Voting Requirements > > Before voting +1 you are required to download the signed source code > package, compile it as provided, and test the resulting executable on > your own platform, along with also verifying that the package meets > the requirements of the ASF policy on releases - > http://www.apache.org/legal/release-policy.html#management > > In particular, you should (at least) follow these steps. > > 1. Download the artefact to be voted on and unzip it. > 2. Check that the artefact does not contain any jar files (there are > branding folders with the name *.jar). > 3. Verify the cryptographic signatures, the NOTICE and LICENSE file > 4. Build it using the README provided by the artefact. > 5. Look in nbbuild/netbeans for the NetBeans installation created by > the build process and try running it. > > In addition to checking the sources, you should check the associated > convenience binary zips, nbms and maven staging at the artefact links > above. As well as checking any artefact functions correctly, you > should check that it has been correctly signed by a PMC member, and > that the source being voted on is sufficient to build the relevant > binary. > > Separate votes will be held on other convenience binaries, including > installers. Those will be dependent on this vote passing. > > This vote is going to be open at least 72 hours, vote with +1, 0, and > -1 as usual. (Please justify -1) > > Please mark your vote with (binding) only if you're an Apache NetBeans > PMC member to help with voting admin. > > Only respond if you are going to vote, i.e., this is NOT a discussion thread. > > Apache NetBeans 16 will be released if and when this vote passes. > > Thank you to all contributors for all your hard work! > > Best wishes, > > Neil, Eric, Geertjan and Martin > Apache NetBeans release team > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [PLUGINS][RELEASES] Preparation for NetBeans 16 plugins
Hi, Am Montag, dem 21.11.2022 um 10:20 + schrieb Neil C Smith: > On Sun, 20 Nov 2022 at 16:50, Ernie Rael wrote: > > > > On 22/11/20 2:30 AM, Neil C Smith wrote: > > > On Fri, 28 Oct 2022 at 10:04, Neil C Smith wrote: > > > So, we made a decision to hold fire on the release vote on this. The > > > plugin catalog does now have some plugins in it, and at least enough > > > to test setup. > > > > What is preventing previously verified plugins, with no known problems, > > from being put into a verified state for the NB16 catalog? > > No idea! I, for one, hope we can move to this by NB17. > > What is a definite is that NB17 freezes and branches Jan ~15th. We > require a configured and populated plugin catalog for NB17 *before* > that date. The answer is simple: It is a new behavior for the plugin portal and thus will need agreement. I might or might not work on this and create a prototype, but I won't promise anything. What won't motivate me are ultimatiums. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Sending NB16 notice to plugin authors (was: Re: [PLUGINS][RELEASES] Preparation for NetBeans 16 plugins)
Hi Ernie, hi Junichi, Am Dienstag, dem 15.11.2022 um 19:19 -0800 schrieb Ernie Rael: > On 22/11/15 4:56 PM, Junichi Yamamoto wrote: > > Hi, > > > > I haven't received it yet... > I haven't seen it either. > you both saw a misconfiguration of the netbeans-vm1 server. The server (tried to) send the mail directly, which was refused by both of your email providers. Daniel Gruno (Apache Infra) took care of the problem and the email queue was flushed today. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Sending NB16 notice to plugin authors (was: Re: [PLUGINS][RELEASES] Preparation for NetBeans 16 plugins)
Hi, Am Mittwoch, dem 16.11.2022 um 17:26 + schrieb Neil C Smith: > From a release perspective, we have certain fixed dates where we need > things in place in the plugin portal. just say, that you or someone else wants admin priviledges. I have no problem switching PMC members to admin status and thus giving them the ability to create versions (and thus empty catalogs) and send informations out. > If the current portal and > process cannot meet those requirements, then we need to replace it. As one of the people doing actually work on the portal, I get fed up by people knowing "the right" way and don't do it. This comment is not so much directed at you Neil, but more on the general tone of this debate, which just plain makes me ignore these emails as the just annoy me. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Sending NB16 notice to plugin authors (was: Re: [PLUGINS][RELEASES] Preparation for NetBeans 16 plugins)
Hi, I'll send the message to the plugin portal authors now. Greetings Matthias Am Dienstag, dem 01.11.2022 um 10:19 +0100 schrieb Jiří Kovalský: > Hi Matthias, > > I agree that it's not a good idea to separate these notification e- > mails depending on primary/secondary authors. We certainly want to > inform all authors. As for the text it could be something like the > following: > ___ > Subject: Check your plugin with the new Apache NetBeans version! > > Hey %1$s, > > have you heard of the new Apache NetBeans version on the horizon? > Yes, the NetBeans community is going to release version %4$s soon! In > order to have your great plugin(s) available on the NetBeans Update > Center also for users of the new version please consider testing the > plugin(s) with the latest RC build and possibly submit new > verification request(s) via the Plugin Portal website. > Your plugins: > %3$s > Direct link to the list of your plugins: > %2$s/plugin/list > Thanks for your contribution and ongoing support! > Apache NetBeans Plugin Portal Administrator > P.S.: Please contact dev@netbeans.apache.org mailing list for any > questions. > ___ > > I hope it makes sense. Please note I have introduced a new %4$s > variable which would contain the latest NetBeans version - perhaps > identified by the greatest ID. Also please consider expanding the > value of %2$s variable to point to the My Plugins page instead of the > homepage. > > -Jirka > > Dne út 1. 11. 2022 8:10 uživatel Matthias Bläsing > napsal: > > [Resend directly, as I'm not sure you monitor > > dev@netbeans.apache.org] > > > > Hi again, > > > > I merged the update and put it into production. A preview message > > was > > correctly delivered to my mailbox. > > > > @Jiří: when you tested you already seemed to have some message in > > mind. > > Would you mind sending it? I suggest to not limit the recipients > > and > > send it to all authors. The numbers are not that high, that we > > really > > need the distinction. > > > > Thank you > > > > Matthias > > > > > > Am Freitag, dem 21.10.2022 um 23:21 +0200 schrieb Matthias Bläsing: > > > Hi, > > > > > > I implemented an e-mail sending option for the plugin portal. > > This > > > should allow us to inform current authors of the plugin portal > > about > > > new NetBeans versions being available for verification. > > > > > > @Jiří: You are still listed as verifier in my test portal, so you > > could > > > have a look at a working implementation: > > > > > > https://doppel-helix.eu/pp3/ > > > > > > The PR for this with a Screenshot can be found here: > > > > > > https://github.com/apache/netbeans-tools/pull/53 > > > > > > I'd like to get an opinion on this. > > > > > > Greetings > > > > > > Matthias > > > > > > > > > > > > Am Mittwoch, dem 19.10.2022 um 13:15 +0100 schrieb Neil C Smith: > > > > Hi, > > > > > > > > Just setting up the infrastructure for NetBeans 16 in advance > > of > > > > 16-rc1. Please can we have an endpoint for NetBeans 16 plugins > > as > > > > soon as possible? > > > > > > > > Can we, perhaps, start with automatically verifying everything > > from > > > > NB15 this time too? It would be much better for testing > > release > > > > candidates. > > > > > > > > Thanks, > > > > > > > > Neil > > > > > > > > --- > > -- > > > > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > > > > For additional commands, e-mail: dev-h...@netbeans.apache.org > > > > > > > > For further information about the NetBeans mailing lists, > > visit: > > > > > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > > > > > > > > > > > > > > > > > > - > > > > > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > > > For additional commands, e-mail: dev-h...@netbeans.apache.org > > > > > > For further information about the NetBeans mailing lists, visit: > > > > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > > > > > > > > > > > > --- > > -- > > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > > For additional commands, e-mail: dev-h...@netbeans.apache.org > > > > For further information about the NetBeans mailing lists, visit: > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > > > > >
Re: [PLUGINS][RELEASES] Preparation for NetBeans 16 plugins
Hi again, I merged the update and put it into production. A preview message was correctly delivered to my mailbox. @Jiří: when you tested you already seemed to have some message in mind. Would you mind sending it? I suggest to not limit the recipients and send it to all authors. The numbers are not that high, that we really need the distinction. Thank you Matthias Am Freitag, dem 21.10.2022 um 23:21 +0200 schrieb Matthias Bläsing: > Hi, > > I implemented an e-mail sending option for the plugin portal. This > should allow us to inform current authors of the plugin portal about > new NetBeans versions being available for verification. > > @Jiří: You are still listed as verifier in my test portal, so you could > have a look at a working implementation: > > https://doppel-helix.eu/pp3/ > > The PR for this with a Screenshot can be found here: > > https://github.com/apache/netbeans-tools/pull/53 > > I'd like to get an opinion on this. > > Greetings > > Matthias > > > > Am Mittwoch, dem 19.10.2022 um 13:15 +0100 schrieb Neil C Smith: > > Hi, > > > > Just setting up the infrastructure for NetBeans 16 in advance of > > 16-rc1. Please can we have an endpoint for NetBeans 16 plugins as > > soon as possible? > > > > Can we, perhaps, start with automatically verifying everything from > > NB15 this time too? It would be much better for testing release > > candidates. > > > > Thanks, > > > > Neil > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > > For additional commands, e-mail: dev-h...@netbeans.apache.org > > > > For further information about the NetBeans mailing lists, visit: > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: plugin built with 16-RC2 won't install on 15
Hi Ernie,
sorry, but you expect more from binary compatibility than java
provides. The TL;DR version is, that you can't have both: Features from
a newer release and methods from an older release. The same is true for
the JDK. You can compile with "--release 8", but then you don't get
access to new features or you use "-target 8" and "-source 8" but then
you get linked against new methods, which don't exist in JDK 8 (see the
ByteBuffer example).
For your case you can work around it. Change:
Comparable specVersion = mi.getSpecificationVersion();
Comparable reqVersion = new SpecificationVersion("9.26");
if (specVersion.compareTo(reqVersion)) >= 0) { // etc etc
To:
Method bridgeImplementation = Comparable.class.getMethod("compareTo",
Object.class);
Comparable specVersion = mi.getSpecificationVersion();
Comparable reqVersion = new SpecificationVersion("9.26");
if (((int)bridgeImplementation.invoke(specVersion, reqVersion)) >= 0) { //
etc etc
Lets hope, that this is the only call to a generified Comparable. Of
course this need to be done for every call, that goes into a generified
method.
Greetings
Matthias
-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: plugin built with 16-RC2 won't install on 15
Hi again,
Am Donnerstag, dem 27.10.2022 um 20:51 +0100 schrieb Neil C Smith:
> On Thu, 27 Oct 2022 at 20:14, Matthias Bläsing
> wrote:
> > Am Donnerstag, dem 27.10.2022 um 20:32 +0200 schrieb Michael Bien:
> > > I am still a bit surprised that this causes issues. Since the class is
> > > final which removes an entire can of worms of potential override issues.
> > > I would have expected the JVM to find the right method in unambiguous
> > > cases like this.
> >
> > [wrong reasoning]
>
> I'm not sure that's correct from the JVM perspective. The Object
> method should still be generated as a bridge?
>
> It should be backwards compatible but it's not forwards compatible?
> Anything compiled against 15 should run on 16, but anything compiled
> against 16 won't run on 15?
>
> I still think it's probably a good idea to revert in this particular
> case though.
you are right and my reasoning was wrong. I looked at the generated
code with javap and there I see:
public int compareTo(org.openide.modules.SpecificationVersion);
descriptor: (Lorg/openide/modules/SpecificationVersion;)I
flags: (0x0001) ACC_PUBLIC
public int compareTo(java.lang.Object);
descriptor: (Ljava/lang/Object;)I
flags: (0x1041) ACC_PUBLIC, ACC_BRIDGE, ACC_SYNTHETIC
The second method is the bridge method you talked about.
So when you build against NB16 the compiler will link against the first
method, when build against NB15 the compiler will link against the
second variant.
So this is a binary compatible change as code linked against the old
version will continue to work (via the bridge). The opposite is not
true.
The solution is "simple": Build against NB15 and execute on NB15 or
newer.
Similar problems can be observed, when you use ByteBuffer#flip.
Compiled against JDK 11 code will not run on JDK 8. although in theory
the method exists, but it has a different return signature:
import java.nio.ByteBuffer;
class test {
public static void main(String[] argv){
ByteBuffer bb = ByteBuffer.allocate(10);
bb.flip();
}
}
Build this with a JDK 11+ once as
javac -source 8 -target 8 test.java
and once as
javac --release 8 test.java
Try to run both:
$PATH_JDK8/bin/java -cp . test
It first fails, the second works. The difference can be seen with
javap:
javap -c -cp . test
So this is already a reality for java developers and indeed it will
continue to happen. The variant you compile against is your lowest
baseline.
Greetings
Matthias
PS: Sorry for the confusion I caused.
-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-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: plugin built with 16-RC2 won't install on 15
Hi, Am Donnerstag, dem 27.10.2022 um 20:32 +0200 schrieb Michael Bien: > On 27.10.22 20:17, Neil C Smith wrote: > > On Thu, 27 Oct 2022, 19:03 Ernie Rael, wrote: > > > > > This is very strange. If I build the plugin on 15 it runs on 15. If I > > > build it with 16-RC2 it will not install on 15. I noticed this a few > > > days ago, but wanted to wait for RC2 before mentioning it. > > > > > > I'll try to narrow it down, wondering if anyone has some ideas about this. > > > > > It'll be caused by https://github.com/apache/netbeans/pull/4678 > > > > Downside of adding generics. Still time to review, although I assume the > > reverse situation isn't affected? > > i kept it in the second commit and didn't squash just in case we have a > situation like this. > > https://github.com/apache/netbeans/pull/4678/commits/50086abd421200ce33bd4508580a80518f350f63 > > I am still a bit surprised that this causes issues. Since the class is > final which removes an entire can of worms of potential override issues. > I would have expected the JVM to find the right method in unambiguous > cases like this. from the JVMs perspective, you removed a method that takes an arbitrary object and added a method that takes a SpecificationVersion. The message to the outside is: - before I was prepare to take any object and will do sane things with it - after I will only care about SpecificiationVersion instances In the implementation the "before" promise is broken as the first instruction is a checked cast, but it is the developer of the method breaking other peoples assumptions, not the JVM. TL;DR: This is an API incompatible change and this was caught by sigtest as the signature file was modified. I suggest to revert that change as the underlying assumption about compatible changes was wrong. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [PLUGINS][RELEASES] Preparation for NetBeans 16 plugins
Hi, I implemented an e-mail sending option for the plugin portal. This should allow us to inform current authors of the plugin portal about new NetBeans versions being available for verification. @Jiří: You are still listed as verifier in my test portal, so you could have a look at a working implementation: https://doppel-helix.eu/pp3/ The PR for this with a Screenshot can be found here: https://github.com/apache/netbeans-tools/pull/53 I'd like to get an opinion on this. Greetings Matthias Am Mittwoch, dem 19.10.2022 um 13:15 +0100 schrieb Neil C Smith: > Hi, > > Just setting up the infrastructure for NetBeans 16 in advance of > 16-rc1. Please can we have an endpoint for NetBeans 16 plugins as > soon as possible? > > Can we, perhaps, start with automatically verifying everything from > NB15 this time too? It would be much better for testing release > candidates. > > Thanks, > > Neil > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [PLUGINS][RELEASES] Preparation for NetBeans 16 plugins
Hi, Am Donnerstag, dem 20.10.2022 um 19:07 +0200 schrieb Michael Bien: > plugins with an impl dependency on something in the IDE shouldn't install. please read first: https://github.com/apache/netbeans/pull/4619 and https://github.com/apache/netbeans/pull/4696 After that please reevaluate your absolute statement or explain how else users of SwingX should be supported. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [PLUGINS][RELEASES] Preparation for NetBeans 16 plugins
Hi, Am Donnerstag, dem 20.10.2022 um 18:35 +0200 schrieb Michael Bien: > what if we leave the process as is for now but keep plugins in the > catalog if there were verified within the last 2-3 releases. > > This would also fix the problem of having an empty catalog on every new > release. > > I think this might improve the situation until there is a better solution. and will break, if the plugin has a hard dependency on the target NetBeans version. We recently had a discussion here about access to flatlaf internals, which is required to get additional flatlaf modules working. There is a high probability, that this will requirere updates on every NetBeans version. greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [PLUGINS][RELEASES] Preparation for NetBeans 16 plugins
Hi, Am Mittwoch, dem 19.10.2022 um 13:15 +0100 schrieb Neil C Smith: > Just setting up the infrastructure for NetBeans 16 in advance of > 16-rc1. Please can we have an endpoint for NetBeans 16 plugins as > soon as possible? I created 16 as version, so the catalog is there and can be selected in the plugin portal. > Can we, perhaps, start with automatically verifying everything from > NB15 this time too? It would be much better for testing release > candidates. This is harder and needs discussion. The process is: 1. Developer created plugin 2. Developer maps plugin version to NetBeans version 3. Developer requests verification for the Plugin version <-> NetBeans version combo 4. Verifier verifies the plugin So we need to decide how the new process should look like, then we can see how that can be accomplished. What I had in my was this: Add a tool to the plugin portal, that allows administrators to send emails to all plugin owners informing them about the new version. That way the original flow is kept, verifiers will not be faced with known broken plugins and plugin authors are aware of the update. I seriously missed requesting verification for newer versions. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: master isn't using the GA version of javac 19 right now
Hi, Am Sonntag, dem 16.10.2022 um 13:12 +0200 schrieb Michael Bien: > just to clarify: it doesn't even have to be an installer, NB itself > could check during boot if the runtime JDK meets the requirements, and > if it doesn't -> offer to download one which does. why do you want to destroy the ease of the OS independed ZIP? Currently I can use NetBeans with OpenJDK 11 or 17 (I have both installed) and it just works. Where do you draw the line? The javac interface is not API, so you'd need to tie the NetBeans installation to a single JDK and vendor. This raises question about bugfixing and security of the chosen JDK. For me this does not fly. Greetings Matthias - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Shall NetBeans improve Java/JDK? With Frgaal?
Hi, I think if a new maven/gradle/ant project is created, it should use mainline technology, without to much fuzz. I estimate, that the OpenJDK javac has a high enough bus-factor, that it should be save, even if one or even multiple of the big players (Oracle, Red Hat, Azul, Amazon, Microsoft) decide to drop the ball. I doubt that about the frgaal fork. A backporting compiler will always be a compromise what it can support and even the frgaal page admits that. There are developers out there, that already struggle with Java on the normal JDK, with a backporting compiler it will even be harder to explain them , why their code broke. I imagine discussions like: "Yeah frgaal can do X, but Y is not supported. You should also be aware, that feature Z is only half there! Oh and features A, B and C are API/JDK level, so no, you won't get them either." Experienced developers, that can understand the implications, can trivially switch to frgaal or ecj and benefit from their advanced features. The change to the pom proposed in PR-4682 switches the compiler plugin for maven, which is also documentated in the frgaal documenation and takes about 10 seconds to copy. Another point: Java 8 or 11 syntax is not that bad. Yes multiline strings are nice, yes enhances switch syntax is nice, but in my mind they are not a reason to risk creating incompatible code. Greetings Matthias Am Mittwoch, dem 05.10.2022 um 19:47 +0200 schrieb Jaroslav Tulach: > Hi. > Recently I brought [Frgaal retrofit compiler](http://frgaal.org) to your > attention again. There was a [PR-4682](https://github.com/apache/netbeans/ > pull/4682) and then a discussion in the thread about (not) supporting ecj in > NetBeans: https://lists.apache.org/list.html?dev@netbeans.apache.org - thank > you for your comments. > > It all boils down to a simple question: Shall NetBeans try to improve > shortcomings of the JDK? > > I have recently given a talk [Forget/Ignore Kotlin, use Java19](https:// > www.youtube.com/watch?v=ua-8ySwFgqg). There is a slide describing the > benefits > of Kotlin around 5th minute. Clearly the fact that the Kotlin language > quickly > evolves and still can be used to generate JDK8 code is a huge benefit. > > Frgaal (described around 25 minute) can do the same. It has been modeled to > mimic the Kotlin model: > - language specification independent of the JDK > - compiler version specified as part of project build script > > Moreover Frgaal is 100% compatible with future Java language specification - > easy to drop it after switching to newest JDK. Overall it is way easier to > adopt latest Java thru Frgaal than trying to switch to a completely new > language. Why do I have to explain it again and again? > > NetBeans can support Frgaal without any problems as it is also (just like nb- > javac) a member of the Javac family. All these compilers generate exactly the > same errors and provide the same WYSIWYG experience. Same errors in the IDE, > same on the command line, same on the CI. > > All that is needed is: We have to realize that "innovation happens elsewhere" > and make Java better than the one produced by the JDK team! > > Anyone has guts to follow better-than-JDK vision? Then let me integrate > Frgaal > into NetBeans and bring the latest Java language features to users of older > JDKs. > -jt > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Supporting ecj in NetBeans
Hi, I'm the author of the referenced comment: https://github.com/apache/netbeans/pull/4682#issuecomment-1257208904 there is not integration of anything into the IDE. It is about making "new" JDK features available to older bytecode targets. For this the default maven javac is replaced by a fork of the OpenJDK javac named frgaal. In my comment I argue, that frgaal has little chance to ever upstream its modifications to the javac. To my knowledge (sorry I have no reference), it is a pretty clear decision of the OpenJDK developers, that they don't want to implement a backporting compiler and it was also an explicit decision, that the class version is bumped on each JDK release independend of the question whether the bytecode really changed. The latter, again from my memory, because compiling against a newer JDK also implies using new APIs and thus is a protection mechanism. But there is an elephant in the room, which is ecj. Contrary to the OpenJDK javac ejc has had backporting capabilities for a long time. What is more ecj is the backend of Eclipse, which gives it, in my mind, some OpenJDK fork. It also has better version coverage, which currently (version 3.31.0) ranges from 1.3 to 18. Given that OpenJDK is dropping support for 1.7, this is impressive. If ecj can't compile code, that OpenJDK can compile or create different behavior, it is either an error in one of the two javac or in the JLS. I would people let use their runtime JDK as basis, then they get consistent results. Everything else (especially backporting compilation) is an advanced topic, that should be considered by people, that know what they are doing. Greetings Matthias Am Mittwoch, dem 28.09.2022 um 22:31 +0200 schrieb Jaroslav Tulach: > Supporting `ecj` in NetBeans makes no/little sense. Let's have a discussion > to > agree on that. > > Few times in the past (most recently at > https://github.com/apache/netbeans/ > pull/4682#issuecomment-1257208904) there was a note suggesting to support > `ecj`. Usually such suggestion appears whenever I propose to use http:// > frgaal.org retrofit compiler. > > Using `ecj` makes no sense - the biggest strength of NetBeans is its WYSIWYG > nature - errors in the editor are exactly the same as errors one gets on > command line when executing `mvn` or `gradlew`. That's because NetBeans > relies > on the family of Javac compilers - be it `javac` from the latest JDK or our > own `nb-javac` port. > > `ecj` is completely different compiler. It has own bugs, own view of Java > source code and it can never achieve the same WYSIWYG experience as `javac` > in > NetBeans provides. Supporting `ecj` seems like a step backwards. I am not > going to stop anyone working on `ecj` support, but I believe the NetBeans > project will have better prospects when it adheres to the family of Javac > compilers. > > As an author of https://cwiki.apache.org/confluence/display/NETBEANS/ > Overview%3A+nb-javac plan, I believe there is no use of `ecj` in NetBeans. > -jt > > PS: Yes, Frgaal does belong into the Javac family. It is a slightly modified > version of the `javac` from the latest JDK that removes the (artificial) > limitation that prevents `target < source`. > > > - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
