And additional:

you also say in issue 61187

>> Only the root of the netbeans.org CVS tree is accepted, i.e. that folder
containing "nbbuild" etc. as a child. If the file chooser does not already
enforce this, it should.

NO,it does not enforce,I was able to add even empty folders...

> ...supposed to be able to use a ZIP of NB sources...

This should be permitted. But sources we are distributing contains netbeans-src
as a toplevel entry. So probably we should adjust behaviour to this. Or better
to both cases - i.e. whether nbbuild or netbeans-src/nbbuild entry is inside of
the zip.

> I was able to add even empty folders...

See issue 62730, where the problem with adding arbitrary directory will be
solved as well.

I've tried a crummy workaround on this: unpack distributed zip and pack it again
without netbeans-src at top level, so that nbbuild is directly in root of ziped
file..but it also does not work, seems like filechooser is not sensitive for
ordinary files, only for directories.

> filechooser is not sensitive for ordinary files, only for directories

exactly

I guess recognizing nbbuild/ as a second-level directory would be wise.

Let's say started. I'll also update UI spec accordingly.

Apparently I'll have to parse all project.xml files of all module entries
similar to the way how NetBeansOrgEntry are created - to obtain CNBs. This will
be presuambly quite slow (probably slower than scanning NB_CVS_DIR).
Also to be precise I should also read "src.dir" property, maybe more (probably
could be skipped for 5.0 - "src" hardcoded). So probably CNB from project.xml of
each up-to-3rd level subdirectory of nb-src.zip!/**/nbbuild/.. should be enough.
Am I correct or there is something I don't see or better way (from performance
point of view) how to solve this issue. Any tips?

Uh, I'm not sure what you're asking about, exactly. Behavior should be that any
dir or ZIP should be accepted in the filechooser so long as either

1. It is a nb.org checkout - meaning contains "nbbuild" subdir, and you can do a
couple of other checks here.

2. For a ZIP file only, it contains "nbbuild" as a subsubdir, in which case the
parent is treated as the root.

3. The dir is a suite project directory (can check for a nbproject/project.xml
matching suite type). Remember that you are permitted to add sources and Javadoc
for suites to a binary platform, in case the platform is a derived platform
which was built from that suite.

I don't see any case where we need to scan arbitrary modules for anything...?

I've been talking not about FileChooser but about the moment when user press "Go
To Source" on e.g. the TopComponent in the editor. So it will call my
SourceForBinaryQueryImplementation.findSourceRoots() implementation with e.g.
..../org-openide-windows.jar!/ as a parameter. 
And here I have to find appropriate nb-src.zip!/...$nbproject.../src.
I could probably utilize ModuleEntry.getNetBeansOrgPath() (I can find a ME in
supposed platform similar to GlobalJavadocForBinaryImpl) or something similar or
create a cache of cnb-directory_in_nbcvs. Not sure yet. I'll take a look on it more.

Oh, you mean because the current SFBQI impl in apisupport works only on loadable
module projects, and you cannot load a module project from inside a ZIP file
(since it is an Ant-based project). Bummer.

May be tricky to fix, so feel free to defer to a post-5.0 release; I think we
can live with requiring people to unpack sources before use.

Exactly. Currect SFBQI implementation is used only through
ProjectSourceForBinaryQuery.
So I would register another SFBQI (e.g. NbPlatformSFBQI, or Global....) to solve
this case.
I think that trick similar to GlobalJFBI would work. I'll obtain CNB from the
given parameter, I'll guess supposed platform (which should be already parsed),
obtain ME, obtain netbeansOrgPath and then I can find the path in nb-src.zip
without any unzipping/parsing. Just a fast idea without too much investigation,
maybe naive and non-working :). I'll give it (or something similar) a fast try.

"obtain ME, obtain netbeansOrgPath and then I can find the path in nb-src.zip
without any unzipping/parsing" - won't work, I think. There will only be a
BinaryModuleEntry, with no netbeansOrgPath.

> There will only be a BinaryModuleEntry, with no netbeansOrgPath.
Ummm.... you are right.

Anyway I have a basic version which works. Also performance is acceptable... for
me :) Just going through the zip and doing only really neccessary things. On my
machine first invocation takes about 3s (could be easily done when the zip is
added in the NB Platform Manager), others calls are immediate (cached for the
IDE session in the meantime). I'll commit till the end of the week, probably
tommorow.

Fixed. Also having simple semi-test working with hardcoded nbsrc.zip. I'll try
to adjust them to use generated pseudo nbsrc.zip and commit.

Checking in
src/META-INF/services/org.netbeans.spi.java.queries.SourceForBinaryQueryImplementation;
1.4 --> 1.5
Checking in queries/GlobalSourceForBinaryImpl.java; 1.1
Checking in ui/platform/NbPlatformCustomizerSources.form; 1.2 --> 1.3
Checking in ui/platform/NbPlatformCustomizerSources.java; 1.4 --> 1.5
Checking in universe/ModuleList.java; 1.17 --> 1.18

> Behavior should be that any
> dir or ZIP should be accepted in the filechooser so long as either
> ...
> 2. For a ZIP file only, it contains "nbbuild" as a subsubdir, in which case the
> parent is treated as the root

Filechooser currently accepts whatever ZIP you like..even empty:(

See the subject. This is another bug with lesser importance (P4 probably).
Please file another issue to keep things clear (i.e. keep this one P2). Dik.

OK, the main problem is solved and works fine. Verified in custom build on sol.
Don't forget to add the tests..

> Also having simple semi-test working with hardcoded nbsrc.zip.
> I'll try to adjust them to use generated pseudo nbsrc.zip and commit.

Checking in test/project/queries/GlobalSourceForBinaryImplTest.java; 1.1