Seems like a projects API problem --> re-assigning.

so you have the sources in winelist, but the project files in winelist- folder, right?

This happens when you create two Java projects from existing sources for a source root, first project placed in a different directory, the second as parent of the source root.

I've managed to reproduce from scratch, here are the steps (build from 20091113):
0. unzip the attached sources somewhere (contains 'myprj' folder).
1. Create a new Java project from existing sources next to the 'myprj' folder, specify myprj/src as the source root.
2. The project shows errors - there's a GUI form that needs Swing Layout Extension Library.
3. Close the project.
If you now shut down the IDE you'll see the externalOwners.properties file in userdir.
4. Create another project from existing sources - now select 'myprj' as the project dir. Specify myprj/src as the source root. So the second project is parent of the source root, not an external owner.
5. Now open project properties and add the missing Swing Layout Extensions library (don't do that via Libraries node in the explorer). But the errors are still shown.

Now you have a correctly set up project, but still complaining about missing classes. If you exit IDE and delete the externalOwners.properties file, it gets fixed. Also if you again open the first project and add the library, the second project gets fixed as well.

BTW if you in step 5 try to add the library via the Libraries node, it is not added to its project, but to the first one (already closed), which is pretty strange.

Created attachment 91329 [details]
source root for reproducing

FileOwnerQuery searches upward in the source tree for either (1) a project directory, (2) an external owner for a dir if one has been registered (even in a previous IDE session). It sounds like the search starting at winelist/src is encountering winelist- as external owner before encountering winelist.

We probably cannot change the search algorithm and in fact sometimes it is correct; people often put NB project metadata in a side folder and want it to own some part of a main source tree, which should not get broken just because they happen to also have a project dir in an upper folder.

In this case the problem is likely that SourcesHelper does not bother to register the project as an owner of a source root in case the root is beneath the project directory, assuming that it would be considered the owner anyway - which this bug shows is not a safe assumption. Perhaps this can be changed, though I am not positive that will not break something else.

Should also make sure that FOQ ignores and deletes persisted registrations for owner projects which no longer seem to exist on disk.

Created attachment 91353 [details]
Idea for patch, untested and lacking test coverage

> Should also make sure that FOQ ignores and deletes persisted registrations
> for owner projects which no longer seem to exist on disk.

I've seen this happening. The file with external owners is deleted after read from preferences during IDE start, written again on shutdown. When I deleted the project, it was not written to the file anymore.

Re. comment #3 from Tomas Pavek:

I tried to reproduce the setup, but instead of closing not completely configured project (3), I fixed the missing reference right away and then I closed the project.

Then after creating second project with ext. sources (referencing source root that was already referenced in first project) both projects are opened and do not show any problem with broken library. 

Re. projects from billshannon:

I'm having hard time to understand the setup and relation of those two projects. Both contain src folder with same source files and bunch of other files that are in one source root and not in the other. In other words it's not clear which project references (or is meant to reference) which sources.

When I created setup described by Tomas Pavek project.properties from both projects define file reference for source root - one in form of 'src' the other as '../myprj/src'. But it is not case for projects from billshannon. Only one of those project defines 'file.reference.winelist-src=src', but not the other one. billshannon, did you do any manual editing to project.xml or project.properties? 

Other question: what is purpose of such setup? It seems to me that one project is some old version and the other is supposed to be new version and is referencing source root from the old version project.

It's been far too long since I created these projects so I can't tell you
how they got to be like they are.  I don't believe I manually edited any
of the files NetBeans creates.

Again, the origin of the two projects is that originally the "winelist"
project was managed by Teamware.  At some point I moved the directory to
"winelist-" and created "winelist" as the same code managed by Mercurial.
Possibly I created a new NetBeans project and imported the existing sources
and told it to manage the new sources with Mercurial.

I just don't remember, sorry.  You'll have to tell me what I could've possibly
done that would've set up the configuration I have.

I don't intend that the "winelist" project should reference *anything* in
the "winelist-" directory.  How it came to do that, I don't know.

"The file with external owners is deleted after read from preferences during IDE start, written again on shutdown. When I deleted the project, it was not written to the file anymore." - yes... but it looks like the old external owner information is retained in memory for the first IDE session, which is too long in this case. The SFOQI part of my patch might address this. Again, untested.

I don't think this is P2. Reporter had two different NetBeans projects on disk referring to the same source root (as far as I can make out). This is generally not supported, and the old project metadata should have been deleted; NB is at fault for not giving preference to the more recently created project when determining the owner of the source root.

Changes to external root registration logic are too risky for 6.9.

This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue.

Thanks for your cooperation,
NetBeans IDE 8.2 Release Boss