[jira] [Commented] (NETBEANS-5380) Background scanning spends significant time in o.n.m.j.mx.project.SuiteFileOwnerQueryImpl#getOwner
[
https://issues.apache.org/jira/browse/NETBEANS-5380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17293389#comment-17293389
]
Jaroslav Tulach commented on NETBEANS-5380:
---
Everything seems to work in NetBeans 12.0, 12.3 as well as with [your
patch|https://github.com/matthiasblaesing/netbeans/commit/460042be723b28b430f88c77c1ee7ab18f364892].
To reproduce try:
{code:java}
graal/truffle$ mx build
graal/truffle$ mx netbeansinit
graal/truffle$ netbeans --open
src/com.oracle.truffle.api/src/com/oracle/truffle/api/frame/Frame.java
{code}
and when the {{Frame.java}} file is opened in the editor, press _Ctrl-Shift-1_.
It always opens the right project. E.g.
{{graal/truffle/src/com.oracle.truffle.api}} in case of 12.0 and
{{graal/truffle}} in case of new NetBeans. Thanks a lot for the fix, Matthias!
> Background scanning spends significant time in
> o.n.m.j.mx.project.SuiteFileOwnerQueryImpl#getOwner
> --
>
> Key: NETBEANS-5380
> URL: https://issues.apache.org/jira/browse/NETBEANS-5380
> Project: NetBeans
> Issue Type: Bug
> Components: java - Source
>Affects Versions: Next
>Reporter: Matthias Bläsing
>Assignee: Jaroslav Tulach
>Priority: Major
> Attachments: sample1.npss, sample2.npss
>
>
> I opened an angular project into an IDE build from recent master. I observed,
> that a very (> 20 minutes) long background scanning times could be observed.
> I first used visual VM and then the netbeans internal profiler to try to
> narrow it down.
> *Profile*
> I'll attach two self profiles, both show the same picture, so I'll
> concentrate on _sample2.npss_:
> There are 9 entries in the self profile, that show CPU times > 190s. From
> these 8 are waiting in native code and thus false positives:
> - ReferenceHandler
> - FileSystemWatchService
> - process reaper (3x)
> - StreamTerm.Output (2x)
> - pool-5-thread-1 (From the trace LSP integration)
> The one trace, that is connected to the observed scanning and is in java code
> is _RepositoryUpdater.worker._ Breaking this down shows, that, although the
> forward calls split into two branches, both hit:
> _org.netbeans.modules.java.mx.project.SuiteFileOwnerQueryImpl#getOwner_
> That method is responsible for 178s CPU time. No other FileOwnerQueryImpl
> shows up in the trace, and thus this leads me to the conclusion, that this is
> fishy.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-5380) Background scanning spends significant time in o.n.m.j.mx.project.SuiteFileOwnerQueryImpl#getOwner
[ https://issues.apache.org/jira/browse/NETBEANS-5380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17293366#comment-17293366 ] Jaroslav Tulach commented on NETBEANS-5380: --- I'll do some testing, but the solution seems to be very promising. Thanks for bringing it up. > Background scanning spends significant time in > o.n.m.j.mx.project.SuiteFileOwnerQueryImpl#getOwner > -- > > Key: NETBEANS-5380 > URL: https://issues.apache.org/jira/browse/NETBEANS-5380 > Project: NetBeans > Issue Type: Bug > Components: java - Source >Affects Versions: Next >Reporter: Matthias Bläsing >Assignee: Jaroslav Tulach >Priority: Major > Attachments: sample1.npss, sample2.npss > > > I opened an angular project into an IDE build from recent master. I observed, > that a very (> 20 minutes) long background scanning times could be observed. > I first used visual VM and then the netbeans internal profiler to try to > narrow it down. > *Profile* > I'll attach two self profiles, both show the same picture, so I'll > concentrate on _sample2.npss_: > There are 9 entries in the self profile, that show CPU times > 190s. From > these 8 are waiting in native code and thus false positives: > - ReferenceHandler > - FileSystemWatchService > - process reaper (3x) > - StreamTerm.Output (2x) > - pool-5-thread-1 (From the trace LSP integration) > The one trace, that is connected to the observed scanning and is in java code > is _RepositoryUpdater.worker._ Breaking this down shows, that, although the > forward calls split into two branches, both hit: > _org.netbeans.modules.java.mx.project.SuiteFileOwnerQueryImpl#getOwner_ > That method is responsible for 178s CPU time. No other FileOwnerQueryImpl > shows up in the trace, and thus this leads me to the conclusion, that this is > fishy. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-5380) Background scanning spends significant time in o.n.m.j.mx.project.SuiteFileOwnerQueryImpl#getOwner
[ https://issues.apache.org/jira/browse/NETBEANS-5380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292066#comment-17292066 ] Matthias Bläsing commented on NETBEANS-5380: Thank you for the explanation - with the generated projects indeed I found, that the SimpleFileOwnerQueryImplementation will normally return the wrong project. With this in mind I reverted the question: How could we prevent netbeans from recognizing the legacy projects when MX support is present? I came up with this: [https://github.com/matthiasblaesing/netbeans/commit/460042be723b28b430f88c77c1ee7ab18f364892] The problem from my POV is, that org.netbeans.modules.project.ant.AntBasedProjectFactorySingleton will recognize the ant based project and legacy project support kicks in. But NetBeans supports multiple projects per project and will default to the one with the ProjectFactory of the lowest position. So two thing are done in the above patch: # org.netbeans.modules.java.mx.project.SuiteFactory got a position and that position is lower than the one from AntBasedProjectFactorySingleton # The factory was modified, to detect MX project not only for the current directory, but also two levels up What do you think? I'll switch to a build with this merged and see if it does what I expect it to do. > Background scanning spends significant time in > o.n.m.j.mx.project.SuiteFileOwnerQueryImpl#getOwner > -- > > Key: NETBEANS-5380 > URL: https://issues.apache.org/jira/browse/NETBEANS-5380 > Project: NetBeans > Issue Type: Bug > Components: java - Source >Affects Versions: Next >Reporter: Matthias Bläsing >Assignee: Jaroslav Tulach >Priority: Major > Attachments: sample1.npss, sample2.npss > > > I opened an angular project into an IDE build from recent master. I observed, > that a very (> 20 minutes) long background scanning times could be observed. > I first used visual VM and then the netbeans internal profiler to try to > narrow it down. > *Profile* > I'll attach two self profiles, both show the same picture, so I'll > concentrate on _sample2.npss_: > There are 9 entries in the self profile, that show CPU times > 190s. From > these 8 are waiting in native code and thus false positives: > - ReferenceHandler > - FileSystemWatchService > - process reaper (3x) > - StreamTerm.Output (2x) > - pool-5-thread-1 (From the trace LSP integration) > The one trace, that is connected to the observed scanning and is in java code > is _RepositoryUpdater.worker._ Breaking this down shows, that, although the > forward calls split into two branches, both hit: > _org.netbeans.modules.java.mx.project.SuiteFileOwnerQueryImpl#getOwner_ > That method is responsible for 178s CPU time. No other FileOwnerQueryImpl > shows up in the trace, and thus this leads me to the conclusion, that this is > fishy. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-5380) Background scanning spends significant time in o.n.m.j.mx.project.SuiteFileOwnerQueryImpl#getOwner
[
https://issues.apache.org/jira/browse/NETBEANS-5380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17289757#comment-17289757
]
Jaroslav Tulach commented on NETBEANS-5380:
---
I could modify the {{mx netbeansinit}} generator to leave a note in the
{{nbproject/project.properties}} to skip ownership, if there is a project
relative to this Ant project. Then the workflow would be:
* use global query and find the Ant project
* the Ant project would find the MX project on NetBeans 12.3 and delegate to it
* the Ant project wouldn't find anything on older NetBeans and would handle
the ownership
This way we could get rid of the global mx.FileOwnerQuery and let the price be
payed only for those who are dealing with {{mx}} built projects.
> Background scanning spends significant time in
> o.n.m.j.mx.project.SuiteFileOwnerQueryImpl#getOwner
> --
>
> Key: NETBEANS-5380
> URL: https://issues.apache.org/jira/browse/NETBEANS-5380
> Project: NetBeans
> Issue Type: Bug
> Components: java - Source
>Affects Versions: Next
>Reporter: Matthias Bläsing
>Assignee: Jaroslav Tulach
>Priority: Major
> Attachments: sample1.npss, sample2.npss
>
>
> I opened an angular project into an IDE build from recent master. I observed,
> that a very (> 20 minutes) long background scanning times could be observed.
> I first used visual VM and then the netbeans internal profiler to try to
> narrow it down.
> *Profile*
> I'll attach two self profiles, both show the same picture, so I'll
> concentrate on _sample2.npss_:
> There are 9 entries in the self profile, that show CPU times > 190s. From
> these 8 are waiting in native code and thus false positives:
> - ReferenceHandler
> - FileSystemWatchService
> - process reaper (3x)
> - StreamTerm.Output (2x)
> - pool-5-thread-1 (From the trace LSP integration)
> The one trace, that is connected to the observed scanning and is in java code
> is _RepositoryUpdater.worker._ Breaking this down shows, that, although the
> forward calls split into two branches, both hit:
> _org.netbeans.modules.java.mx.project.SuiteFileOwnerQueryImpl#getOwner_
> That method is responsible for 178s CPU time. No other FileOwnerQueryImpl
> shows up in the trace, and thus this leads me to the conclusion, that this is
> fishy.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-5380) Background scanning spends significant time in o.n.m.j.mx.project.SuiteFileOwnerQueryImpl#getOwner
[ https://issues.apache.org/jira/browse/NETBEANS-5380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288180#comment-17288180 ] Jaroslav Tulach commented on NETBEANS-5380: --- OK, that'd be ideal. > Background scanning spends significant time in > o.n.m.j.mx.project.SuiteFileOwnerQueryImpl#getOwner > -- > > Key: NETBEANS-5380 > URL: https://issues.apache.org/jira/browse/NETBEANS-5380 > Project: NetBeans > Issue Type: Bug > Components: java - Source >Affects Versions: Next >Reporter: Matthias Bläsing >Assignee: Jaroslav Tulach >Priority: Major > Attachments: sample1.npss, sample2.npss > > > I opened an angular project into an IDE build from recent master. I observed, > that a very (> 20 minutes) long background scanning times could be observed. > I first used visual VM and then the netbeans internal profiler to try to > narrow it down. > *Profile* > I'll attach two self profiles, both show the same picture, so I'll > concentrate on _sample2.npss_: > There are 9 entries in the self profile, that show CPU times > 190s. From > these 8 are waiting in native code and thus false positives: > - ReferenceHandler > - FileSystemWatchService > - process reaper (3x) > - StreamTerm.Output (2x) > - pool-5-thread-1 (From the trace LSP integration) > The one trace, that is connected to the observed scanning and is in java code > is _RepositoryUpdater.worker._ Breaking this down shows, that, although the > forward calls split into two branches, both hit: > _org.netbeans.modules.java.mx.project.SuiteFileOwnerQueryImpl#getOwner_ > That method is responsible for 178s CPU time. No other FileOwnerQueryImpl > shows up in the trace, and thus this leads me to the conclusion, that this is > fishy. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-5380) Background scanning spends significant time in o.n.m.j.mx.project.SuiteFileOwnerQueryImpl#getOwner
[ https://issues.apache.org/jira/browse/NETBEANS-5380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288064#comment-17288064 ] Matthias Bläsing commented on NETBEANS-5380: The core question: Why is _SimpleFileOwnerQueryImplementation_ good enough for every project in netbeans, but not for MX, because when you look at the implementation, they follow the same pattern and they _*both*_ come down to: ProjectManager.getDefault().findProject(file) The difference I see is, that: * SimpleFileOwnerQueryImplementation does aggressive caching * has a special implementation to resolve parent URL * does not bother to try to find a suite.py * has some more filtering and handling of project ownership My gut feeling from a quick look over the code: Dropping the special implementation of FileOwnerQueryImplementation in the mx project support could already solve the problem, as from my perspective it brings nothing to the table, that the implementation in projectui already does. > Background scanning spends significant time in > o.n.m.j.mx.project.SuiteFileOwnerQueryImpl#getOwner > -- > > Key: NETBEANS-5380 > URL: https://issues.apache.org/jira/browse/NETBEANS-5380 > Project: NetBeans > Issue Type: Bug > Components: java - Source >Affects Versions: Next >Reporter: Matthias Bläsing >Assignee: Jaroslav Tulach >Priority: Major > Attachments: sample1.npss, sample2.npss > > > I opened an angular project into an IDE build from recent master. I observed, > that a very (> 20 minutes) long background scanning times could be observed. > I first used visual VM and then the netbeans internal profiler to try to > narrow it down. > *Profile* > I'll attach two self profiles, both show the same picture, so I'll > concentrate on _sample2.npss_: > There are 9 entries in the self profile, that show CPU times > 190s. From > these 8 are waiting in native code and thus false positives: > - ReferenceHandler > - FileSystemWatchService > - process reaper (3x) > - StreamTerm.Output (2x) > - pool-5-thread-1 (From the trace LSP integration) > The one trace, that is connected to the observed scanning and is in java code > is _RepositoryUpdater.worker._ Breaking this down shows, that, although the > forward calls split into two branches, both hit: > _org.netbeans.modules.java.mx.project.SuiteFileOwnerQueryImpl#getOwner_ > That method is responsible for 178s CPU time. No other FileOwnerQueryImpl > shows up in the trace, and thus this leads me to the conclusion, that this is > fishy. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-5380) Background scanning spends significant time in o.n.m.j.mx.project.SuiteFileOwnerQueryImpl#getOwner
[
https://issues.apache.org/jira/browse/NETBEANS-5380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288051#comment-17288051
]
Jaroslav Tulach commented on NETBEANS-5380:
---
It is always good to enable the (although improper) _"Hit Count"_ to see where
the loops occur. Checking the second sample and the RepositoryUpdater.worker
thread I see:
*
org.netbeans.modules.html.editor.lib.api.SyntaxAnalyzerResult$ElementContentFilter.getMasks()
6x
*
org.netbeans.modules.html.editor.lib.api.SyntaxAnalyzerResult$ElementContentFilter.shouldBeFiltered()
3280x
then it goes to:
*
org.netbeans.modules.parsing.spi.indexing.support.QuerySupport.reduceRootsByProjects()
3306x
* org.netbeans.modules.java.mx.project.SuiteFileOwnerQueryImpl.getOwner() 3642x
One option would be to decrease the number of calls to {{getOwner()}} when
parsing. The other is to improve {{mx}} - the problem there is that mx checks
for project two levels deep. A folder is Mx project if it contains {{mx.*}}
subfolder and that folder contains {{suite.py}} file. FileSystems API isn't
particularly fast in checking that.
I'll think about an improvement. Thanks for bug report.
> Background scanning spends significant time in
> o.n.m.j.mx.project.SuiteFileOwnerQueryImpl#getOwner
> --
>
> Key: NETBEANS-5380
> URL: https://issues.apache.org/jira/browse/NETBEANS-5380
> Project: NetBeans
> Issue Type: Bug
> Components: java - Source
>Affects Versions: Next
>Reporter: Matthias Bläsing
>Assignee: Jaroslav Tulach
>Priority: Major
> Attachments: sample1.npss, sample2.npss
>
>
> I opened an angular project into an IDE build from recent master. I observed,
> that a very (> 20 minutes) long background scanning times could be observed.
> I first used visual VM and then the netbeans internal profiler to try to
> narrow it down.
> *Profile*
> I'll attach two self profiles, both show the same picture, so I'll
> concentrate on _sample2.npss_:
> There are 9 entries in the self profile, that show CPU times > 190s. From
> these 8 are waiting in native code and thus false positives:
> - ReferenceHandler
> - FileSystemWatchService
> - process reaper (3x)
> - StreamTerm.Output (2x)
> - pool-5-thread-1 (From the trace LSP integration)
> The one trace, that is connected to the observed scanning and is in java code
> is _RepositoryUpdater.worker._ Breaking this down shows, that, although the
> forward calls split into two branches, both hit:
> _org.netbeans.modules.java.mx.project.SuiteFileOwnerQueryImpl#getOwner_
> That method is responsible for 178s CPU time. No other FileOwnerQueryImpl
> shows up in the trace, and thus this leads me to the conclusion, that this is
> fishy.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-5380) Background scanning spends significant time in o.n.m.j.mx.project.SuiteFileOwnerQueryImpl#getOwner
[ https://issues.apache.org/jira/browse/NETBEANS-5380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17287810#comment-17287810 ] Matthias Bläsing commented on NETBEANS-5380: @jtulach could you please have a look at this? > Background scanning spends significant time in > o.n.m.j.mx.project.SuiteFileOwnerQueryImpl#getOwner > -- > > Key: NETBEANS-5380 > URL: https://issues.apache.org/jira/browse/NETBEANS-5380 > Project: NetBeans > Issue Type: Bug > Components: java - Source >Affects Versions: Next >Reporter: Matthias Bläsing >Priority: Major > Attachments: sample1.npss, sample2.npss > > > I opened an angular project into an IDE build from recent master. I observed, > that a very (> 20 minutes) long background scanning times could be observed. > I first used visual VM and then the netbeans internal profiler to try to > narrow it down. > *Profile* > I'll attach two self profiles, both show the same picture, so I'll > concentrate on _sample2.npss_: > There are 9 entries in the self profile, that show CPU times > 190s. From > these 8 are waiting in native code and thus false positives: > - ReferenceHandler > - FileSystemWatchService > - process reaper (3x) > - StreamTerm.Output (2x) > - pool-5-thread-1 (From the trace LSP integration) > The one trace, that is connected to the observed scanning and is in java code > is _RepositoryUpdater.worker._ Breaking this down shows, that, although the > forward calls split into two branches, both hit: > _org.netbeans.modules.java.mx.project.SuiteFileOwnerQueryImpl#getOwner_ > That method is responsible for 178s CPU time. No other FileOwnerQueryImpl > shows up in the trace, and thus this leads me to the conclusion, that this is > fishy. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-5380) Background scanning spends significant time in o.n.m.j.mx.project.SuiteFileOwnerQueryImpl#getOwner
[ https://issues.apache.org/jira/browse/NETBEANS-5380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17287809#comment-17287809 ] Matthias Bläsing commented on NETBEANS-5380: These are the Implementations that can be found in-tree, that are not not test implementations: _apisupport/apisupport.ant/src/org/netbeans/modules/apisupport/project/queries/UpdateTrackingFileOwnerQuery.java_ -> Assoziates nbms/jars built from modules _ide/projectui/src/org/netbeans/modules/project/ui/ProjectsRootNode.java_ -> Associates files under project node with FileOwnerQuery _ide/projectapi/src/org/netbeans/modules/projectapi/SimpleFileOwnerQueryImplementation.java_ -> "Real directory scanning" _java/maven/src/org/netbeans/modules/maven/queries/MavenFileOwnerQueryImpl.java_ -> Associates maven local repository path with open maven project _java/jshell.support/src/org/netbeans/modules/jshell/env/ShellOwnerQueryImpl.java_ -> Selects files from a hashmap Looking at __ _ide/projectapi/src/org/netbeans/modules/projectapi/SimpleFileOwnerQueryImplementation.java_ there is an aggressive Cache for the project association, which is totally missing from _SuiteFileOwnerQueryImpl_. This leads to two questions: * why has MX suite its own _FileOwnerQueryImplementation_ and is not relying on the implementation from _projectapi_? * would it make sense to implement a cache like the implementation from _projectapi_ > Background scanning spends significant time in > o.n.m.j.mx.project.SuiteFileOwnerQueryImpl#getOwner > -- > > Key: NETBEANS-5380 > URL: https://issues.apache.org/jira/browse/NETBEANS-5380 > Project: NetBeans > Issue Type: Bug > Components: java - Source >Affects Versions: Next >Reporter: Matthias Bläsing >Priority: Major > Attachments: sample1.npss, sample2.npss > > > I opened an angular project into an IDE build from recent master. I observed, > that a very (> 20 minutes) long background scanning times could be observed. > I first used visual VM and then the netbeans internal profiler to try to > narrow it down. > *Profile* > I'll attach two self profiles, both show the same picture, so I'll > concentrate on _sample2.npss_: > There are 9 entries in the self profile, that show CPU times > 190s. From > these 8 are waiting in native code and thus false positives: > - ReferenceHandler > - FileSystemWatchService > - process reaper (3x) > - StreamTerm.Output (2x) > - pool-5-thread-1 (From the trace LSP integration) > The one trace, that is connected to the observed scanning and is in java code > is _RepositoryUpdater.worker._ Breaking this down shows, that, although the > forward calls split into two branches, both hit: > _org.netbeans.modules.java.mx.project.SuiteFileOwnerQueryImpl#getOwner_ > That method is responsible for 178s CPU time. No other FileOwnerQueryImpl > shows up in the trace, and thus this leads me to the conclusion, that this is > fishy. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
