Re: NetBeans 12.0, Groovy and Java 14
Big +1 to update to Groovy 2.5.10 Benjamin On 19.03.2020 06:11, Geertjan Wielenga wrote: > Yes, we can include this in one of the betas, if Eric permits, as release > manager. > > Gj > > On Wed, 18 Mar 2020 at 23:54, Sven Reimers wrote: > >> Hi all, >> >> seems there is an issue with the Groovy version provided with NetBeans wrt >> running on top of Java 14 - some class not found stuff which occurs during >> parsing. >> >> Seems the easy fix would be to update to latest Groovy 2.5.x series, which >> should fix the issue. >> >> I would try to create a PR for this, if everyone agrees that this would be >> good to have on NetBeans 12.0 - else I may just look at getting latest >> Groovy 3.0.x ready for NetBeans 12.x >> >> Comments? >> >> -Sven >> >> -- >> Sven Reimers >> >> * Java Champion >> * Apache NetBeans PMC: http://netbeans.apache.org >> * JUG Leader JUG Bodensee: https://www.meetup.com/JUG-Bodensee >> * Duke's Choice Award Winner 2009 & 2018 >> >> * LinkedIn: http://www.linkedin.com/in/svenreimers >> signature.asc Description: OpenPGP digital signature
Re: NetBeans 12.0, Groovy and Java 14
Yes, we can include this in one of the betas, if Eric permits, as release manager. Gj On Wed, 18 Mar 2020 at 23:54, Sven Reimers wrote: > Hi all, > > seems there is an issue with the Groovy version provided with NetBeans wrt > running on top of Java 14 - some class not found stuff which occurs during > parsing. > > Seems the easy fix would be to update to latest Groovy 2.5.x series, which > should fix the issue. > > I would try to create a PR for this, if everyone agrees that this would be > good to have on NetBeans 12.0 - else I may just look at getting latest > Groovy 3.0.x ready for NetBeans 12.x > > Comments? > > -Sven > > -- > Sven Reimers > > * Java Champion > * Apache NetBeans PMC: http://netbeans.apache.org > * JUG Leader JUG Bodensee: https://www.meetup.com/JUG-Bodensee > * Duke's Choice Award Winner 2009 & 2018 > > * LinkedIn: http://www.linkedin.com/in/svenreimers >
NetBeans 12.0, Groovy and Java 14
Hi all, seems there is an issue with the Groovy version provided with NetBeans wrt running on top of Java 14 - some class not found stuff which occurs during parsing. Seems the easy fix would be to update to latest Groovy 2.5.x series, which should fix the issue. I would try to create a PR for this, if everyone agrees that this would be good to have on NetBeans 12.0 - else I may just look at getting latest Groovy 3.0.x ready for NetBeans 12.x Comments? -Sven -- Sven Reimers * Java Champion * Apache NetBeans PMC: http://netbeans.apache.org * JUG Leader JUG Bodensee: https://www.meetup.com/JUG-Bodensee * Duke's Choice Award Winner 2009 & 2018 * LinkedIn: http://www.linkedin.com/in/svenreimers
New committer: Hector Espert
Hi, The Project Management Committee (PMC) for Apache NetBeans has invited Hector Espert to become a committer and we are pleased to announce that he has accepted. Best Regards Matthias Bläsing on behalf of the Apache NetBeans PMC - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-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: Problems of (dark) FlatLaF
I've created a PR to fix issue NETBEANS-3942 (breakpoint color): https://github.com/apache/netbeans/pull/2031 The problem was that the editor has additional storage for annotations, which was not updated when switching color profile on NB shutdown (after LaF switch). If you already have wrong colors (after switching LaF), the PR does and can not fix them. In this case it is necessary to either reapply color profile in NB Options dialog or switch to FlatLaf Light and then back to FlatLaf Dark. Karl On 12.03.2020 06:17, Laszlo Kishalmi wrote: I've noticed this behavior as well. I've tried, but I cannot find out how to reproduce it at will or what could be the root cause of it. So the workaround is after laf changes just reapply the color scheme. On 3/11/20 1:29 AM, Alessandro wrote: Hi Jaroslav, Regarding the second one (3942) I sometimes faced it especially when switching between color profiles or look and feels which recommend a color profile. The colors of breakpoints and execution line are defined in the FlatLaf color profile and are consistent with the others. What you are probably seeing are the colors of a light color profile. It seems that some colors are not overwritten by the switch and kept to the previous value. Please try to reset them to the color profile definition by using the reset button in the annotations tab and see if that fixes it. Unfortunately you will lose any tweak you made after the switch. Hope it helps. Alex Il giorno mer 4 mar 2020 alle 09:23 Jaroslav Tulach < jaroslav.tul...@gmail.com> ha scritto: Hi. FlatLaF is nice, but it has few problems. I've reported: https://issues.apache.org/jira/browse/NETBEANS-3943 https://issues.apache.org/jira/browse/NETBEANS-3942 https://issues.apache.org/jira/browse/NETBEANS-3910 Is there a guy who feels responsible for these issues? On a general note: How do we make sure FlatLaF related issues got assigned to the right people? What category to use? How to identify them? -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: Debugger very slow/stuck
I'll try to reproduce it by running NetBeans itself in debugging mode: I'll keep you posted. On Wed, 18 Mar 2020 at 09:40, Geertjan Wielenga wrote: > What can we do to reproduce this? > > Gj > > On Wed, 18 Mar 2020 at 16:17, Matteo Di Giovinazzo > wrote: > > > Hello, > > this is a problem we keep having with the NetBeans Debugger in our NB > > Platform application, but it seems a general problem with the Java > > debugger. It is here since years but lately it is really unusable: cannot > > really debug at all... See below. > > > > Anyone else having this problem? It is so unusable we are thinking to > > migrate from NetBeans Platform to IntelliJ platform so we can use > IntelljJ > > as the IDE for developing it. > > > > See https://issues.apache.org/jira/browse/NETBEANS-4037 > > > > We have a pretty big NetBeans Platform Application (~180 modules and 5 > > > suites) and when the debugger reaches the first breakpoint it got > stuck: > > > the tabs Debugging, Variables, Breakpoints, etc. are all with a "Please > > > wait..." node and with the NetBeans sampler I took a few snapshots > > > highlighting it is spending a lot of time on calls like: > > > > > >- org.netbeans.modules.debugger.jpda.ui.SourcePath.getURL() > > >- org.netbeans.modules.debugger.jpda.ui.SourcePath.annotate() > > > > > > which at the end boil down to a lot of calls like: > > > > > >- java.util.concurrent.CopyOnWriteArrayList.remove() > > >- java.io.File.isFile() > > > > > > Attached the snapshots. > > > Then if I press Continue the debugger remain stuck: now Pause and > > Continue > > > buttons in the toolbar are disabled... > > > I kept close and restarting NetBeans but no luck... I remember got this > > > behavior even with NB 8.2, sometimes though it goes through and I'm > able > > to > > > debug, but very rarely! > > > > > > Thanks for any help, hint to solve this problem! > > -- > > Matteo Di Giovinazzo > > > -- Matteo Di Giovinazzo
Re: Debugger very slow/stuck
What can we do to reproduce this? Gj On Wed, 18 Mar 2020 at 16:17, Matteo Di Giovinazzo wrote: > Hello, > this is a problem we keep having with the NetBeans Debugger in our NB > Platform application, but it seems a general problem with the Java > debugger. It is here since years but lately it is really unusable: cannot > really debug at all... See below. > > Anyone else having this problem? It is so unusable we are thinking to > migrate from NetBeans Platform to IntelliJ platform so we can use IntelljJ > as the IDE for developing it. > > See https://issues.apache.org/jira/browse/NETBEANS-4037 > > We have a pretty big NetBeans Platform Application (~180 modules and 5 > > suites) and when the debugger reaches the first breakpoint it got stuck: > > the tabs Debugging, Variables, Breakpoints, etc. are all with a "Please > > wait..." node and with the NetBeans sampler I took a few snapshots > > highlighting it is spending a lot of time on calls like: > > > >- org.netbeans.modules.debugger.jpda.ui.SourcePath.getURL() > >- org.netbeans.modules.debugger.jpda.ui.SourcePath.annotate() > > > > which at the end boil down to a lot of calls like: > > > >- java.util.concurrent.CopyOnWriteArrayList.remove() > >- java.io.File.isFile() > > > > Attached the snapshots. > > Then if I press Continue the debugger remain stuck: now Pause and > Continue > > buttons in the toolbar are disabled... > > I kept close and restarting NetBeans but no luck... I remember got this > > behavior even with NB 8.2, sometimes though it goes through and I'm able > to > > debug, but very rarely! > > > Thanks for any help, hint to solve this problem! > -- > Matteo Di Giovinazzo >
Re: help needed wth communiy-uml
UML is part of 6th donation currently being worked on. jhall and jsearch are part of JavaHelp no longer part of NetBeans. Gj On Wed, 18 Mar 2020 at 15:41, Jeremy Cavanagh wrote: > Hi All, > > Congratulations to everyone involved in the release of NB 11.3, it's > definitely the best yet! The FlatLF is quite delightful and has sorted > out many little display problems quite simply terrific. I have been > using it since its release, previously 11.3beta3 was also good. > > I have a question about the community UML package, has it been donated > to Apache Netbeans as Geertjan suggested might happen in his email dated > 11/02/2020? > > After receiving this message, I downloaded both UML and XML packages to > look at them. Since then I have been through the UML package (more than > once) and reformatted everything, eliminating all the random and > unhelpful line-breaks, differentiating the javadoc comments from in-line > code comments and commented out code, and eliminated any manual > formatting so that the formatting is done only using the built in > formatter. I think the end result is more readable (for me at least, I > suspect others might disagree, but I never liked the standard coding > style). Since that I have started trying to work through all the > indicated errors to see if it will build. I've managed to get somewhere > with the aid of innumerable internet searches,bu, finally have come to a > bit of a standstill with the following error: > > ant -f "/Volumes/MBP-Seagate/002 - > PROGRAMMING/Local-Git-Repos/community-uml/uml" > -Dcontinue.after.failing.tests=true build > taskdefs: > common-init: > projectized-common.basic-init: > basic-init: > files-init: > nbm-license-init: > build-init: > Scanning for modules in /Applications/Develop/NetBeans/Apache NetBeans > 11.3.app/Contents/Resources/NetBeans/netbeans/harness > Scanning for modules in /Applications/Develop/NetBeans/Apache NetBeans > 11.3.app/Contents/Resources/NetBeans/netbeans/ide > Scanning for modules in /Applications/Develop/NetBeans/Apache NetBeans > 11.3.app/Contents/Resources/NetBeans/netbeans/java > Scanning for modules in /Applications/Develop/NetBeans/Apache NetBeans > 11.3.app/Contents/Resources/NetBeans/netbeans/nb > Scanning for modules in /Applications/Develop/NetBeans/Apache NetBeans > 11.3.app/Contents/Resources/NetBeans/netbeans/platform > Scanning for modules in /Applications/Develop/NetBeans/Apache NetBeans > 11.3.app/Contents/Resources/NetBeans/netbeans/websvccommon > Scanning for modules in suite /Volumes/MBP-Seagate/002 - > PROGRAMMING/Local-Git-Repos/community-uml > warning: had to upgrade dependencies for module > org.netbeans.modules.uml: added = [module org.netbeans.api.templates > > 1.0, module org.netbeans.api.progress.nb > 1.40, module > org.openide.filesystems.nb, module org.openide.filesystems.compat8] > removed = []; details: [Separation of desktop and cleanup, Swing > dependencies split away, Templates API has been separated into its own > module.] > init: > up-to-date: > compile: > jar-prep: > jar: > netbeans-extra: > unzip-doors: > Expanding: /Volumes/MBP-Seagate/002 - > PROGRAMMING/Local-Git-Repos/community-uml/uml/lib/DoorsIntegrationFiles.zip > > into /Volumes/MBP-Seagate/002 - > PROGRAMMING/Local-Git-Repos/community-uml/build/cluster/modules > languagedefs: > javahelp: > /Applications/Develop/NetBeans/Apache NetBeans > 11.3.app/Contents/Resources/NetBeans/netbeans/harness/build.xml:468: You > must set 'jhall.jar' (e.g. in private.properties) to the location of > jsearch.jar from a JavaHelp distribution > BUILD FAILED (total time: 4 seconds) > > But I can't find anything helpful on the internet about jhall.jar & > jsearch.jar to solve this problem. > > Any help would be much appreciated. > > Regards > > Jeremy > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
Debugger very slow/stuck
Hello, this is a problem we keep having with the NetBeans Debugger in our NB Platform application, but it seems a general problem with the Java debugger. It is here since years but lately it is really unusable: cannot really debug at all... See below. Anyone else having this problem? It is so unusable we are thinking to migrate from NetBeans Platform to IntelliJ platform so we can use IntelljJ as the IDE for developing it. See https://issues.apache.org/jira/browse/NETBEANS-4037 We have a pretty big NetBeans Platform Application (~180 modules and 5 > suites) and when the debugger reaches the first breakpoint it got stuck: > the tabs Debugging, Variables, Breakpoints, etc. are all with a "Please > wait..." node and with the NetBeans sampler I took a few snapshots > highlighting it is spending a lot of time on calls like: > >- org.netbeans.modules.debugger.jpda.ui.SourcePath.getURL() >- org.netbeans.modules.debugger.jpda.ui.SourcePath.annotate() > > which at the end boil down to a lot of calls like: > >- java.util.concurrent.CopyOnWriteArrayList.remove() >- java.io.File.isFile() > > Attached the snapshots. > Then if I press Continue the debugger remain stuck: now Pause and Continue > buttons in the toolbar are disabled... > I kept close and restarting NetBeans but no luck... I remember got this > behavior even with NB 8.2, sometimes though it goes through and I'm able to > debug, but very rarely! Thanks for any help, hint to solve this problem! -- Matteo Di Giovinazzo
Re: Groovy project in Apache NetBeans?
Well, Right now both Maven and Gradle has some Groovy support meaning they are able to display and open projects with Groovy source sets, so including some Groovy project creation wizard would be pretty simple for those. However the Groovy folks like to have things like Grape (in code dependency management) and maybe some other strange things which we do not have support for. BTW Can I put a line to the wish list: Support for mixed compile. What I mean: We have a Groovy project in the Gradle support at: groovy/gradle/netbeans-gradle-tooling which have java and Groovy code mixed. Groovy seems to be able to process the Java code, but Java can't process the Groovy one. BTW I think I need to file an issue on that. On 3/18/20 12:47 AM, Geertjan Wielenga wrote: I'd love to donate my code as a starting point, but it's really old and I have no idea where that source code is, not in my GitHub repos anyway. On top of that, that code was Ant-based. I believe what we need here is a Maven-based project -- i.e., maybe an existing archetype that focuses on Groovy that is already on Maven Central should be registered in the New Project dialog, just like the Payara and Gluon archetypes are? Gj On Tue, Mar 17, 2020 at 9:09 PM Sven Reimers wrote: Sounds cool... Can you donate your code as a starting point? BTW - Talking about wishlist... - Having a Groovy Console in NetBeans would be great as well - Having a Groovy AST navigator view - Groovy 3 Support ;-) I new more spacetime.. -Sven On Tue, Mar 17, 2020 at 8:29 PM Geertjan Wielenga wrote: Hi all, especially Sven (who works a lot in the Groovy area in NetBeans), https://issues.apache.org/jira/browse/NETBEANS-2438 What do we think of the above, would be pretty cool? Who wants to work on this together, maybe with Sven, if he likes the concept? Gj -- Sven Reimers * Java Champion * Apache NetBeans PMC: http://netbeans.apache.org * JUG Leader JUG Bodensee: https://www.meetup.com/JUG-Bodensee * Duke's Choice Award Winner 2009 & 2018 * LinkedIn: http://www.linkedin.com/in/svenreimers - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-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 wth communiy-uml
Hi All, Congratulations to everyone involved in the release of NB 11.3, it's definitely the best yet! The FlatLF is quite delightful and has sorted out many little display problems quite simply terrific. I have been using it since its release, previously 11.3beta3 was also good. I have a question about the community UML package, has it been donated to Apache Netbeans as Geertjan suggested might happen in his email dated 11/02/2020? After receiving this message, I downloaded both UML and XML packages to look at them. Since then I have been through the UML package (more than once) and reformatted everything, eliminating all the random and unhelpful line-breaks, differentiating the javadoc comments from in-line code comments and commented out code, and eliminated any manual formatting so that the formatting is done only using the built in formatter. I think the end result is more readable (for me at least, I suspect others might disagree, but I never liked the standard coding style). Since that I have started trying to work through all the indicated errors to see if it will build. I've managed to get somewhere with the aid of innumerable internet searches,bu, finally have come to a bit of a standstill with the following error: ant -f "/Volumes/MBP-Seagate/002 - PROGRAMMING/Local-Git-Repos/community-uml/uml" -Dcontinue.after.failing.tests=true build taskdefs: common-init: projectized-common.basic-init: basic-init: files-init: nbm-license-init: build-init: Scanning for modules in /Applications/Develop/NetBeans/Apache NetBeans 11.3.app/Contents/Resources/NetBeans/netbeans/harness Scanning for modules in /Applications/Develop/NetBeans/Apache NetBeans 11.3.app/Contents/Resources/NetBeans/netbeans/ide Scanning for modules in /Applications/Develop/NetBeans/Apache NetBeans 11.3.app/Contents/Resources/NetBeans/netbeans/java Scanning for modules in /Applications/Develop/NetBeans/Apache NetBeans 11.3.app/Contents/Resources/NetBeans/netbeans/nb Scanning for modules in /Applications/Develop/NetBeans/Apache NetBeans 11.3.app/Contents/Resources/NetBeans/netbeans/platform Scanning for modules in /Applications/Develop/NetBeans/Apache NetBeans 11.3.app/Contents/Resources/NetBeans/netbeans/websvccommon Scanning for modules in suite /Volumes/MBP-Seagate/002 - PROGRAMMING/Local-Git-Repos/community-uml warning: had to upgrade dependencies for module org.netbeans.modules.uml: added = [module org.netbeans.api.templates > 1.0, module org.netbeans.api.progress.nb > 1.40, module org.openide.filesystems.nb, module org.openide.filesystems.compat8] removed = []; details: [Separation of desktop and cleanup, Swing dependencies split away, Templates API has been separated into its own module.] init: up-to-date: compile: jar-prep: jar: netbeans-extra: unzip-doors: Expanding: /Volumes/MBP-Seagate/002 - PROGRAMMING/Local-Git-Repos/community-uml/uml/lib/DoorsIntegrationFiles.zip into /Volumes/MBP-Seagate/002 - PROGRAMMING/Local-Git-Repos/community-uml/build/cluster/modules languagedefs: javahelp: /Applications/Develop/NetBeans/Apache NetBeans 11.3.app/Contents/Resources/NetBeans/netbeans/harness/build.xml:468: You must set 'jhall.jar' (e.g. in private.properties) to the location of jsearch.jar from a JavaHelp distribution BUILD FAILED (total time: 4 seconds) But I can't find anything helpful on the internet about jhall.jar & jsearch.jar to solve this problem. Any help would be much appreciated. Regards Jeremy - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
RE: SVG Loader visibility in Plugins
I agree with that; I'm happy with the "everything through GitHub" approach. (And the commit during freeze was just an error on my part, not a policy disagreement.) -- Eirik -Original Message- From: Neil C Smith Sent: Wednesday, March 18, 2020 8:29 AM To: dev Subject: Re: SVG Loader visibility in Plugins On Tue, 17 Mar 2020 at 23:37, Eirik Bakke wrote: > My personal policy is to do everything through GitHub PRs, except > trivial changes in code that I originally wrote myself. (I wrote the > SVG loader module in this case.) IMO we should not be doing straight push to the repo whether inside or outside freeze periods, except for a very limited number of cases (security, etc.) where review must obviously be private. Bypassing PRs also bypasses review processes, some archiving and pre-merge testing. Even the entire release process (aside from tags) is done via PR now. I personally have push-url on the upstream set to DISABLED for this reason and use the full git URL for pushing tags (should anyone wonder at the mention of this in the wiki docs on releases). Inside freeze, obviously the release manager needs to be aware of, if not actively merging, every change. Be glad it's Eric - he's more chilled than I am! ;-) 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: SVG Loader visibility in Plugins
On Tue, 17 Mar 2020 at 23:37, Eirik Bakke wrote: > My personal policy is to do everything through GitHub PRs, except trivial > changes in code that I originally wrote myself. (I wrote the SVG loader > module in this case.) IMO we should not be doing straight push to the repo whether inside or outside freeze periods, except for a very limited number of cases (security, etc.) where review must obviously be private. Bypassing PRs also bypasses review processes, some archiving and pre-merge testing. Even the entire release process (aside from tags) is done via PR now. I personally have push-url on the upstream set to DISABLED for this reason and use the full git URL for pushing tags (should anyone wonder at the mention of this in the wiki docs on releases). Inside freeze, obviously the release manager needs to be aware of, if not actively merging, every change. Be glad it's Eric - he's more chilled than I am! ;-) 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: Groovy project in Apache NetBeans?
I'd love to donate my code as a starting point, but it's really old and I have no idea where that source code is, not in my GitHub repos anyway. On top of that, that code was Ant-based. I believe what we need here is a Maven-based project -- i.e., maybe an existing archetype that focuses on Groovy that is already on Maven Central should be registered in the New Project dialog, just like the Payara and Gluon archetypes are? Gj On Tue, Mar 17, 2020 at 9:09 PM Sven Reimers wrote: > Sounds cool... > > Can you donate your code as a starting point? > > BTW - Talking about wishlist... > - Having a Groovy Console in NetBeans would be great as well > - Having a Groovy AST navigator view > - Groovy 3 Support > > ;-) I new more spacetime.. > > -Sven > > On Tue, Mar 17, 2020 at 8:29 PM Geertjan Wielenga > wrote: > > > Hi all, especially Sven (who works a lot in the Groovy area in NetBeans), > > > > https://issues.apache.org/jira/browse/NETBEANS-2438 > > > > What do we think of the above, would be pretty cool? Who wants to work on > > this together, maybe with Sven, if he likes the concept? > > > > Gj > > > > > -- > Sven Reimers > > * Java Champion > * Apache NetBeans PMC: http://netbeans.apache.org > * JUG Leader JUG Bodensee: https://www.meetup.com/JUG-Bodensee > * Duke's Choice Award Winner 2009 & 2018 > > * LinkedIn: http://www.linkedin.com/in/svenreimers >
Re: Groovy project in Apache NetBeans?
Congrats and thanks for joining in. :-) Gj On Tue, Mar 17, 2020 at 9:12 PM Walter Kruse wrote: > I can help with testing and documentation. First time here. I logged the > issue. > > Walter > > On 2020/03/17 19:28:55, Geertjan Wielenga wrote: > > > Hi all, especially Sven (who works a lot in the Groovy area in > NetBeans), > > > > > > https://issues.apache.org/jira/browse/NETBEANS-2438> > > > What do we think of the above, would be pretty cool? Who wants to work on > > > > this together, maybe with Sven, if he likes the concept? > > > > > > Gj > > > > > >
Re: SVG Loader visibility in Plugins
Great, however it ends up. /Patrik Den ons 18 mars 2020 kl 00:52 skrev Eirik Bakke : > Oh, I missed that email... my apologies. Feel free to revert the change > [1], or let me know if you want me to do so myself. > > -- Eirik > [1] > https://github.com/apache/netbeans/commit/3e4fe382e66f547c50438856081d163a831e73fb > > -Original Message- > From: Eric Barboni > Sent: Tuesday, March 17, 2020 7:38 PM > To: dev@netbeans.apache.org > Subject: RE: SVG Loader visibility in Plugins > > Synchronization PR is created. > > We are under merge windows close rules. We are supposed not to merge to > master. > > Best Regards > Eric > > -Message d'origine- > De : Neil C Smith Envoyé : mercredi 18 mars 2020 > 00:04 À : dev Objet : Re: SVG Loader visibility > in Plugins > > On Tue, 17 Mar 2020, 22:01 Eirik Bakke, wrote: > > > It's a new, optional module. Yes, we should probably hide it from the > > Plugins list; I've done this now [1]. > > > > Direct commit to the repo?! > > 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 > > > >
