RE: Profiling on 64bit Windows
Build issues aside, I think the code in the PR actually needs at least a cursory review from someone else than the original author. Others, like myself, have passed by and tested the fix or left other comments, but I'm not sure anyone sat down and reviewed it all in one sitting. ( https://github.com/apache/netbeans/pull/2021 ) -- Eirik -Original Message- From: Ernie Rael Sent: Monday, January 11, 2021 12:34 PM To: dev@netbeans.apache.org Subject: Re: Profiling on 64bit Windows On 1/11/2021 6:53 AM, Geertjan Wielenga wrote: > What needs to be done? Can you provide a PR? Sadly no. I suspect that someone who knows their way around a distribution would have that knowledge. I could be wrong, but I suspect it's simple. If it is simple and it hasn't been done in two years, I'd guess it's more a lack of will or willingness to just check in the binaries. -ernie > > Gj > > On Mon, 11 Jan 2021 at 15:33, Ernie Rael wrote: > >> Hi all, >> >> There's been a fix for the 64 bit windows profiling problem for over >> two years. >> >> https://github.com/pedro-w/netbeans/releases/tag/v0.1-alpha >> https://issues.apache.org/jira/browse/NETBEANS-1428 >> >> AFAICT, it hasn't been integrated. There's some discussion every few >> months or so on how to get the binaries to be automatically built as >> part of the general build. An answer hasn't been found, so the >> problem remains. These binaries have been around and in use for quite a >> while. >> >> This issue seems stuck in the /Perfectionism is the enemy of >> progress/ trap. >> >> Can't the binaries be checked in and included, while the >> investigation for a solution proceeds? >> >> -ernie >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org >> For additional commands, e-mail: dev-h...@netbeans.apache.org >> >> For further information about the NetBeans mailing lists, visit: >> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists >> >> >> >> - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Javafx integration plugins
I would recommend to download the Scene Builder from Gluon and register in the Options window, then it will/should open when you edit an FXML file. Gj On Mon, Jan 11, 2021 at 6:52 PM Gilberto Caetano de Andrade < gilbert...@gmail.com> wrote: > Hello guys! Happy new year! > > Can anyone help me to find the source of the following plugins? > - > http://plugins.netbeans.org/plugin/55434/monet-the-javafx-scene-builder-integration > ; > - http://plugins.netbeans.org/plugin/56440/jfx-fluidon > > Ideally I would like to use one of them, but both are throwing the same > exception: > > [code] > java.lang.ClassNotFoundException: javafx.embed.swing.JFXPanel > at > java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581) > at > java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) > at > org.netbeans.ProxyClassLoader.doFindClass(ProxyClassLoader.java:209) > Caused: java.lang.ClassNotFoundException: javafx.embed.swing.JFXPanel > starting from ModuleCL@234774e4[org.netbeans.jfxfluidon] with possible > defining loaders [ModuleCL@53386959[org.netbeans.libs.javafx]] and > declared parents [ModuleCL@56e3facd[org.netbeans.spi.navigator], > ModuleCL@577c0330[org.openide.windows], ModuleCL@9340099[org.openide.awt], > ModuleCL@384c819b[org.openide.filesystems.nb], > ModuleCL@70c60d70[org.openide.loaders], > org.netbeans.JarClassLoader@61858674, > ModuleCL@d189be6[org.netbeans.api.templates], > ModuleCL@2824dcfa[org.netbeans.core.multiview], > org.netbeans.MainImpl$BootClassLoader@5ae9a829, > ModuleCL@5ba69a89[org.openide.nodes], > ...2 more] > at > org.netbeans.ProxyClassLoader.doFindClass(ProxyClassLoader.java:211) > at > org.netbeans.ProxyClassLoader.loadClass(ProxyClassLoader.java:125) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) > Caused: java.lang.NoClassDefFoundError: javafx/embed/swing/JFXPanel > at > org.netbeans.jfxfluidon.action.FXMLOpenAction$1.run(FXMLOpenAction.java:98) > at > java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313) > at > java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:770) > at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721) > at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715) > at java.base/java.security.AccessController.doPrivileged(Native > Method) > at > java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) > at > java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:740) > at > org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:136) > [catch] at > java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) > at > java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) > at > java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) > at > java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) > at > java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > at > java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) > > [/code] > > So, I have no idea where to report this problem or contribute with some > effort to make it work on NetBeans 12. > > Regards, > > Gilberto > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
Javafx integration plugins
Hello guys! Happy new year! Can anyone help me to find the source of the following plugins? - http://plugins.netbeans.org/plugin/55434/monet-the-javafx-scene-builder-integration; - http://plugins.netbeans.org/plugin/56440/jfx-fluidon Ideally I would like to use one of them, but both are throwing the same exception: [code] java.lang.ClassNotFoundException: javafx.embed.swing.JFXPanel at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) at org.netbeans.ProxyClassLoader.doFindClass(ProxyClassLoader.java:209) Caused: java.lang.ClassNotFoundException: javafx.embed.swing.JFXPanel starting from ModuleCL@234774e4[org.netbeans.jfxfluidon] with possible defining loaders [ModuleCL@53386959[org.netbeans.libs.javafx]] and declared parents [ModuleCL@56e3facd[org.netbeans.spi.navigator], ModuleCL@577c0330[org.openide.windows], ModuleCL@9340099[org.openide.awt], ModuleCL@384c819b[org.openide.filesystems.nb], ModuleCL@70c60d70[org.openide.loaders], org.netbeans.JarClassLoader@61858674, ModuleCL@d189be6[org.netbeans.api.templates], ModuleCL@2824dcfa[org.netbeans.core.multiview], org.netbeans.MainImpl$BootClassLoader@5ae9a829, ModuleCL@5ba69a89[org.openide.nodes], ...2 more] at org.netbeans.ProxyClassLoader.doFindClass(ProxyClassLoader.java:211) at org.netbeans.ProxyClassLoader.loadClass(ProxyClassLoader.java:125) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) Caused: java.lang.NoClassDefFoundError: javafx/embed/swing/JFXPanel at org.netbeans.jfxfluidon.action.FXMLOpenAction$1.run(FXMLOpenAction.java:98) at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313) at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:770) at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721) at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:740) at org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:136) [catch] at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) [/code] So, I have no idea where to report this problem or contribute with some effort to make it work on NetBeans 12. Regards, Gilberto - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Profiling on 64bit Windows
On 1/11/2021 6:53 AM, Geertjan Wielenga wrote: What needs to be done? Can you provide a PR? Sadly no. I suspect that someone who knows their way around a distribution would have that knowledge. I could be wrong, but I suspect it's simple. If it is simple and it hasn't been done in two years, I'd guess it's more a lack of will or willingness to just check in the binaries. -ernie Gj On Mon, 11 Jan 2021 at 15:33, Ernie Rael wrote: Hi all, There's been a fix for the 64 bit windows profiling problem for over two years. https://github.com/pedro-w/netbeans/releases/tag/v0.1-alpha https://issues.apache.org/jira/browse/NETBEANS-1428 AFAICT, it hasn't been integrated. There's some discussion every few months or so on how to get the binaries to be automatically built as part of the general build. An answer hasn't been found, so the problem remains. These binaries have been around and in use for quite a while. This issue seems stuck in the /Perfectionism is the enemy of progress/ trap. Can't the binaries be checked in and included, while the investigation for a solution proceeds? -ernie - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [PROPOSAL] Do not create 13.0 as an LTS for May
On Mon, 11 Jan 2021 at 15:46, Laszlo Kishalmi wrote: > Well, this was a bit of reflection on no response to my "NetBeans 12.3 > Release: Please Prepare!" email. > > We shall be in the API review phase by now. However we are still looking > for a release manager there. > > I would pass on that this time as work became taxing recently (lost a > team member, and inherited a about half a year tech debt). hmmm, I'd missed that thread - been tied up with other work (part of which just finishing off) so less time for NetBeans in the last few months. Maybe bad timing - bump and re-ask? But if need be I can possibly pick up RM on it, just probably not until next week. 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
Help Needed: nb-javac upgrade for 12.0-u2
Dear all, I have a PR upgrading nb-javac for 12.0-u2: https://github.com/apache/netbeans/pull/2672 If we can figure out in one day what needs to be done with it, and get pass the CI, then I'd include it, otherwise I'm going to skip it from 12.0-u2 BTW here is the list of the PR-s which got included: https://github.com/apache/netbeans/pulls?q=is%3Aclosed+milestone%3A12.0-u2 - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: 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 12.2 u1 VSCode Extension
+1 tested the features - refactorings and polyglot debugging. checked SHA512 - match Martin On 11. 01. 21 12:35, Jaroslav Tulach wrote: Dear community, many improvements have been made to [VSNetBeans](https://urldefense.com/v3/__https://cwiki.apache.org/__;!!GqivPVa7Brio!NhQitEclp-Z345X4FxmIox-FYgNOysRmz3X1646vw_8oKsBRG0nGyUxZZiQ_I4OuFw$ confluence/display/NETBEANS/Apache+NetBeans+extension+for+Visual+Studio+Code) during last few weeks. The fixes include stability improvements as well as many new refactoring features and infrastructure enhancements[1]. To follow the gold open source rule to "release early, release offten" I've just packed what has been done and I am calling for a vote on sources for Apache NetBeans 12.2 u1: https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/netbeans-vscode-ext-12.2.1/netbeans-12.2.1-source.zip__;!!GqivPVa7Brio!NhQitEclp-Z345X4FxmIox-FYgNOysRmz3X1646vw_8oKsBRG0nGyUxZZiSYKAvQ8w$ https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/netbeans-vscode-ext-12.2.1/netbeans-12.2.1-source.zip.asc__;!!GqivPVa7Brio!NhQitEclp-Z345X4FxmIox-FYgNOysRmz3X1646vw_8oKsBRG0nGyUxZZiRF_uNLcA$ https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/netbeans-vscode-ext-12.2.1/netbeans-12.2.1-source.zip.sha512__;!!GqivPVa7Brio!NhQitEclp-Z345X4FxmIox-FYgNOysRmz3X1646vw_8oKsBRG0nGyUxZZiQyWO5NUw$ As well as associated convenience binary containing the VSCode extension file for Apache NetBeans Language Server 12.2.1 extension: https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/netbeans-vscode-ext-12.2.1/apache-netbeans-java-12.2.1.vsix__;!!GqivPVa7Brio!NhQitEclp-Z345X4FxmIox-FYgNOysRmz3X1646vw_8oKsBRG0nGyUxZZiQLI5Hyfg$ https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/netbeans-vscode-ext-12.2.1/apache-netbeans-java-12.2.1.vsix.asc__;!!GqivPVa7Brio!NhQitEclp-Z345X4FxmIox-FYgNOysRmz3X1646vw_8oKsBRG0nGyUxZZiSNWeOD8g$ https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/netbeans-vscode-ext-12.2.1/apache-netbeans-java-12.2.1.vsix.sha512__;!!GqivPVa7Brio!NhQitEclp-Z345X4FxmIox-FYgNOysRmz3X1646vw_8oKsBRG0nGyUxZZiT8JBkDdw$ The source ZIP as well as the `.vsix` file come from tag 12.2.1 in our repository: https://urldefense.com/v3/__https://github.com/apache/netbeans/tree/12.2.1__;!!GqivPVa7Brio!NhQitEclp-Z345X4FxmIox-FYgNOysRmz3X1646vw_8oKsBRG0nGyUxZZiSnzA66ug$ - e.g. from commit 7220262. The source ZIP has been produced by TLP job (I've just renamed it to contain 12.2.1 version): https://urldefense.com/v3/__https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/netbeans/job/__;!!GqivPVa7Brio!NhQitEclp-Z345X4FxmIox-FYgNOysRmz3X1646vw_8oKsBRG0nGyUxZZiSveDQPXw$ release122/28/artifact/dist/netbeans/ The `.vsix` file has been produced by https://urldefense.com/v3/__https://ci-builds.apache.org/job/__;!!GqivPVa7Brio!NhQitEclp-Z345X4FxmIox-FYgNOysRmz3X1646vw_8oKsBRG0nGyUxZZiS51nOrLw$ Netbeans/job/netbeans-vscode/257/ job run. I've signed both files with my new GPG key (lost previous one during hard drive crash) which can be found at the end of https://urldefense.com/v3/__https://downloads.apache.org/netbeans/__;!!GqivPVa7Brio!NhQitEclp-Z345X4FxmIox-FYgNOysRmz3X1646vw_8oKsBRG0nGyUxZZiQ4qYowVA$ KEYS - hopefully the signing went OK. To build the Apache NetBeans Language Server extension please follow the instruction in [java/java.lsp.server/vscode/BUILD.md](https://urldefense.com/v3/__https://github.com/__;!!GqivPVa7Brio!NhQitEclp-Z345X4FxmIox-FYgNOysRmz3X1646vw_8oKsBRG0nGyUxZZiR1XjOGwA$ apache/netbeans/blob/c8e0cec5edcbfbd61f22e07eb92fcdbad17f345b/java/ java.lsp.server/vscode/BUILD.md), e.g.: ```bash netbeans$ ant build netbeans$ cd java/java.lsp.server java.lsp.server$ ant build-vscode-ext ``` To test the resulting or convenience `.vsix` file, please follow the [wiki page](https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/NETBEANS/__;!!GqivPVa7Brio!NhQitEclp-Z345X4FxmIox-FYgNOysRmz3X1646vw_8oKsBRG0nGyUxZZiQaJz0iBg$ Apache+NetBeans+extension+for+Visual+Studio+Code) instructions that describe the typical scenarios the extension is supposed to support. Let's give us 72h for testing and voting. Thanks everyone who contributed and everyone who supported this exceptional irregular 12.2 u1 release. -jt [1] Changelog is available https://urldefense.com/v3/__https://github.com/apache/netbeans/blob/__;!!GqivPVa7Brio!NhQitEclp-Z345X4FxmIox-FYgNOysRmz3X1646vw_8oKsBRG0nGyUxZZiQ4U7A7lw$ c8e0cec5edcbfbd61f22e07eb92fcdbad17f345b/java/java.lsp.server/vscode/ CHANGELOG.md - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists,
Re: Semantic versioning or not? was: [PROPOSAL] Do not create 13.0 as an LTS for May
On Mon, 11 Jan 2021 at 15:41, Jaroslav Tulach wrote: > There is a difference between "marketing number" and "technological number". > The > principles of semantic versioning only apply to "technological numbering". We > adhere to > semantic versioning when versining individual modules. > > The "marketing number" for the whole NetBeans IDE has nothing to do with that > and can > be anything. Don't even try to find some logic in that. It is driven by > marketing ideas which > are creative, but not really scientific. I'm well aware of that, but it makes no sense from a marketing perspective either - because it confuses more than it helps! eg. #2 at https://lists.apache.org/thread.html/r15b69940c02f93274b0e7372f4f2d302374589cecbeb0a4f22de4e61%40%3Cdev.netbeans.apache.org%3E :-) If it constantly needs explaining (and I know I've had to), I'm not sure it's driven by sound marketing ideas. 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: [PROPOSAL] Do not create 13.0 as an LTS for May
On 1/11/21 1:23 AM, Neil C Smith wrote: On Mon, 11 Jan 2021 at 02:16, Laszlo Kishalmi wrote: I'd like to express my thought about that our 13.0 meant to be next LTS released in May or early June, does not make much sense. Probably not a surprise, but +1 to this. I'd propose release a 12.4 instead, maybe a 12.5 in September (supporting Java 17) and 13.0 in November, maybe LTS with stable Java 17 support. Agreed that could make sense, *if* we keep an LTS, to make it the *second* release after each Java LTS, and sync those two things up. I know people may make the argument that we're more than a Java IDE, but to me this would also be about the recommended JDK to run with. Also thinking about dropping LTS as it is. Well, until we know what it is! :-) Yes, I meant it in that way! And lastly, I'm feeling that having 4 releases in a year is a bit to many... However, I'm definitely -1 to this. That's not without the caveat of thinking there's room for improvement around API review, issue handling, and testing, etc. leading up to freeze dates, and being stricter about what is allowed into the release branch post-freeze. No more "can we squeeze this change in?" :-) I think less frequent releases actually put more pressure on each release, and we'll end up with inevitably longer release cycles but just as much work. Well, this was a bit of reflection on no response to my "NetBeans 12.3 Release: Please Prepare!" email. We shall be in the API review phase by now. However we are still looking for a release manager there. I would pass on that this time as work became taxing recently (lost a team member, and inherited a about half a year tech debt). If we drop or change LTS as is we might want to rethink what NetCAT is / means too? Maybe as well as a more formal NetCAT with any less frequent LTS, we need to open up and encourage running the various tests against daily builds throughout the year? 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
Semantic versioning or not? was: [PROPOSAL] Do not create 13.0 as an LTS for May
Dne pondělí 11. ledna 2021 10:28:49 CET, Neil C Smith napsal(a): > On Mon, 11 Jan 2021 at 09:18, Tomáš Procházka wrote: > > Versioning scheme > > > > Clearly we don't follow semantic versioning (https://semver.org/). So > > what it means for user to go from 12.3 to 13.0? > > In addition to other points - the versioning scheme was decided > *before* the release schedule. It still makes no sense to me, and > definitely isn't semantic. There is a difference between "marketing number" and "technological number". The principles of semantic versioning only apply to "technological numbering". We adhere to semantic versioning when versining individual modules. The "marketing number" for the whole NetBeans IDE has nothing to do with that and can be anything. Don't even try to find some logic in that. It is driven by marketing ideas which are creative, but not really scientific. -jt Btw. once there was a discussion about BOM https://lists.apache.org/thread.html/ r553224d33753a475334da864f24a956a41cc8c8ac75159d6129e4033%40%3Cdev.netbeans. apache.org%3E[1] it would be great to have it one day as it nicely balances the "marketing uber number" with "technological numbers" of individual modules. [1] https://lists.apache.org/thread.html/ r553224d33753a475334da864f24a956a41cc8c8ac75159d6129e4033%40%3Cdev.netbeans. apache.org%3E
Re: [PROPOSAL] Do not create 13.0 as an LTS for May
Even if we voted on the version scheme once, it does not mean that we can't change that. So yes, we can reopen that discussion. On 1/11/21 1:28 AM, Neil C Smith wrote: On Mon, 11 Jan 2021 at 09:18, Tomáš Procházka wrote: Versioning scheme Clearly we don't follow semantic versioning (https://semver.org/). So what it means for user to go from 12.3 to 13.0? In addition to other points - the versioning scheme was decided *before* the release schedule. It still makes no sense to me, and definitely isn't semantic. And I'm still in favour of moving to single integer - so 13, 14, 15 ... Maybe this can be the catalyst for that? Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Profiling on 64bit Windows
What needs to be done? Can you provide a PR? Gj On Mon, 11 Jan 2021 at 15:33, Ernie Rael wrote: > Hi all, > > There's been a fix for the 64 bit windows profiling problem for over two > years. > > https://github.com/pedro-w/netbeans/releases/tag/v0.1-alpha > https://issues.apache.org/jira/browse/NETBEANS-1428 > > AFAICT, it hasn't been integrated. There's some discussion every few > months or so on how to get the binaries to be automatically built as > part of the general build. An answer hasn't been found, so the problem > remains. These binaries have been around and in use for quite a while. > > This issue seems stuck in the /Perfectionism is the enemy of progress/ > trap. > > Can't the binaries be checked in and included, while the investigation > for a solution proceeds? > > -ernie > > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
Profiling on 64bit Windows
Hi all, There's been a fix for the 64 bit windows profiling problem for over two years. https://github.com/pedro-w/netbeans/releases/tag/v0.1-alpha https://issues.apache.org/jira/browse/NETBEANS-1428 AFAICT, it hasn't been integrated. There's some discussion every few months or so on how to get the binaries to be automatically built as part of the general build. An answer hasn't been found, so the problem remains. These binaries have been around and in use for quite a while. This issue seems stuck in the /Perfectionism is the enemy of progress/ trap. Can't the binaries be checked in and included, while the investigation for a solution proceeds? -ernie - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[CVE-2020-17534] HTML/Java API 1.7: A race condition between deletion of the temporary file and creation of the temporary directory
CVE-ID--CVE-2020-17534 Summary---A race condition between the deletion of the temporary file and creation of the temporary directory There exists a race condition between the deletion of the temporary file and the creation of the temporary directory in `webkit` subproject of HTML/Java API version 1.7. A similar vulnerability has recently been disclosed in other Java projects and the fix in HTML/Java API version 1.7.1 follows theirs: To avoid local privilege escalation version 1.7.1 creates the temporary directory atomically without dealing with the temporary file: https:// github.com/apache/netbeans-html4j/commit/ fa70e507ee1adb4f6518479fc408a7abd0e6[1] --- - Avoid using webkit presenter 1.7 - Update to HTML/Java API 1.7.1 Credit:---The problem was identified by Jonathan Leitschuh [1] https://github.com/apache/netbeans-html4j/commit/ fa70e507ee1adb4f6518479fc408a7abd0e6
[VOTE] Release Apache NetBeans 12.2 u1 VSCode Extension
Dear community, many improvements have been made to [VSNetBeans](https://cwiki.apache.org/ confluence/display/NETBEANS/Apache+NetBeans+extension+for+Visual+Studio+Code) during last few weeks. The fixes include stability improvements as well as many new refactoring features and infrastructure enhancements[1]. To follow the gold open source rule to "release early, release offten" I've just packed what has been done and I am calling for a vote on sources for Apache NetBeans 12.2 u1: https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/netbeans-vscode-ext-12.2.1/netbeans-12.2.1-source.zip https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/netbeans-vscode-ext-12.2.1/netbeans-12.2.1-source.zip.asc https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/netbeans-vscode-ext-12.2.1/netbeans-12.2.1-source.zip.sha512 As well as associated convenience binary containing the VSCode extension file for Apache NetBeans Language Server 12.2.1 extension: https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/netbeans-vscode-ext-12.2.1/apache-netbeans-java-12.2.1.vsix https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/netbeans-vscode-ext-12.2.1/apache-netbeans-java-12.2.1.vsix.asc https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/netbeans-vscode-ext-12.2.1/apache-netbeans-java-12.2.1.vsix.sha512 The source ZIP as well as the `.vsix` file come from tag 12.2.1 in our repository: https://github.com/apache/netbeans/tree/12.2.1 - e.g. from commit 7220262. The source ZIP has been produced by TLP job (I've just renamed it to contain 12.2.1 version): https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/netbeans/job/ release122/28/artifact/dist/netbeans/ The `.vsix` file has been produced by https://ci-builds.apache.org/job/ Netbeans/job/netbeans-vscode/257/ job run. I've signed both files with my new GPG key (lost previous one during hard drive crash) which can be found at the end of https://downloads.apache.org/netbeans/ KEYS - hopefully the signing went OK. To build the Apache NetBeans Language Server extension please follow the instruction in [java/java.lsp.server/vscode/BUILD.md](https://github.com/ apache/netbeans/blob/c8e0cec5edcbfbd61f22e07eb92fcdbad17f345b/java/ java.lsp.server/vscode/BUILD.md), e.g.: ```bash netbeans$ ant build netbeans$ cd java/java.lsp.server java.lsp.server$ ant build-vscode-ext ``` To test the resulting or convenience `.vsix` file, please follow the [wiki page](https://cwiki.apache.org/confluence/display/NETBEANS/ Apache+NetBeans+extension+for+Visual+Studio+Code) instructions that describe the typical scenarios the extension is supposed to support. Let's give us 72h for testing and voting. Thanks everyone who contributed and everyone who supported this exceptional irregular 12.2 u1 release. -jt [1] Changelog is available https://github.com/apache/netbeans/blob/ c8e0cec5edcbfbd61f22e07eb92fcdbad17f345b/java/java.lsp.server/vscode/ CHANGELOG.md - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: 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] Do not create 13.0 as an LTS for May
On Mon, 11 Jan 2021 at 09:18, Tomáš Procházka wrote: > Versioning scheme > > Clearly we don't follow semantic versioning (https://semver.org/). So > what it means for user to go from 12.3 to 13.0? In addition to other points - the versioning scheme was decided *before* the release schedule. It still makes no sense to me, and definitely isn't semantic. And I'm still in favour of moving to single integer - so 13, 14, 15 ... Maybe this can be the catalyst for that? Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [PROPOSAL] Do not create 13.0 as an LTS for May
On Mon, 11 Jan 2021 at 02:16, Laszlo Kishalmi wrote: > I'd like to express my thought about that our 13.0 meant to be next LTS > released in May or early June, does not make much sense. Probably not a surprise, but +1 to this. > I'd propose release a 12.4 instead, maybe a 12.5 in September > (supporting Java 17) and 13.0 in November, maybe LTS with stable Java 17 > support. Agreed that could make sense, *if* we keep an LTS, to make it the *second* release after each Java LTS, and sync those two things up. I know people may make the argument that we're more than a Java IDE, but to me this would also be about the recommended JDK to run with. > Also thinking about dropping LTS as it is. Well, until we know what it is! :-) > And lastly, I'm feeling that having 4 releases in a year is a bit to many... However, I'm definitely -1 to this. That's not without the caveat of thinking there's room for improvement around API review, issue handling, and testing, etc. leading up to freeze dates, and being stricter about what is allowed into the release branch post-freeze. No more "can we squeeze this change in?" :-) I think less frequent releases actually put more pressure on each release, and we'll end up with inevitably longer release cycles but just as much work. If we drop or change LTS as is we might want to rethink what NetCAT is / means too? Maybe as well as a more formal NetCAT with any less frequent LTS, we need to open up and encourage running the various tests against daily builds throughout the year? 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: [PROPOSAL] Do not create 13.0 as an LTS for May
Hi, my opinion on related topics. LTS If I see software release marked as LTS then it is promise of developers to update it for longer time than in regular release. It means lot of work - backporting fixes, testing, complete release process. If it is too much burden, let's don't release another LTS NetBeans. Versioning scheme Clearly we don't follow semantic versioning (https://semver.org/). So what it means for user to go from 12.3 to 13.0? NetBeans is not only for Java, but also supports PHP, HTML, CSS or JavaScript development. I would not tie releasing x.0 version only to new Java release. NetBeans 12.3 with full PHP 8 support (thank you Junichi) is major release for PHP developers ;) NetCAT process associated with x.0 release can send message "this release was tested more thoroughly than feature releases". Release frequency It's good to have regular releases in shorter time frame. It means fixes and new features get to users sooner and there is no need for updates between. I liked how branching and release of NetBeans 12.2 was managed without freezing master branch. It is definitively more encouraging for contribution when you now that PR integration is limited by capacity of reviewers and not by finishing of release. I compile NetBeans from master and use them for daily work to test stability and function. TL;DR - drop LTS release - tie x.0 versions to NetCAT - keep 4 releases/year instead of update releases for LTS Tom On 11. 01. 21 3:16, Laszlo Kishalmi wrote: Dear all, I'd like to express my thought about that our 13.0 meant to be next LTS released in May or early June, does not make much sense. I have two main reasons: 1. Java 17 LTS will be released in September (around 13.1), so the timing is less than ideal 2. We still do not know what do we want from an LTS release. I'd propose release a 12.4 instead, maybe a 12.5 in September (supporting Java 17) and 13.0 in November, maybe LTS with stable Java 17 support. Also thinking about dropping LTS as it is. If anyone would like to step up and support a release longer than the next release, that would be Ok. And lastly, I'm feeling that having 4 releases in a year is a bit to many... -- Laszlo Kishalmi - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists