I tries to change this and succeeded, here is a patch (I initially attached it to one of the issues that are blocked by this one):
http://bugzilla-attachments-197768.netbeans.org/bugzilla/attachment.cgi?id=107836

I do not think I understand the use case - a remote project should have a remote URL for its project directory, and that is what should be shown in Files. Nonetheless, the change seems reasonable; the main reasons for the former logic were

1. Ensure that something is shown even if the project does not have a Sources impl. But ProjectUtils.getSources already has a fallback impl.

2. Produce a warning if there are multiple groups with the project dir in them, or none. But this would seem to conflict with the intent of this issue.

3. Sort the project dir group first. That should be up to the project anyway.

The patch can be simplified; I will attach that. But it breaks ProjectsRootNodeNotRecognizedTest - something to do with lazy projects I do not exactly understand. Perhaps Yarda can explain.

Created attachment 107845 [details]
Running patch

ProjectsRootNode part of the patch causes a test failure.

(In reply to comment #2)
> I do not think I understand the use case
I can formulate another use cases for project from existing sources (where metadata folder and existing sources do not intersect)

1. project have Add New->Source File => it's strange for user to see that metadata folder is proposed as folder where sources can be inserted
2. We'd like Files View for such project to have only one entry - src folder itself. We don't want to show metadata folder (all can be done through project properties UI and no need to give access to project.xml file directly)

Reassigning to evaluate test failure; see comment #2.

The test checks the behavior of the system when a folder is deleted while OpenProjectHook is running. Obviously you are changing the behavior. You can mimic the old behavior, but if you believe behavior should change, you probably have to modify the test to:

        Node child = logicalView.getChildren().getNodeAt(0);
        assertNull("No child at 0", child);

Well I have looked at it again but I do not see any purpose for the ProjectsRootNode part of the patch. Vladimir can this just be omitted, leaving the obvious patch to PhysicalView?

(In reply to comment #7)
> ...I do not see any purpose for the ProjectsRootNode part of the patch
> Vladimir can this just be omitted... 
As I understand, without this change original node will be replaced by Node.EMPTY in the case there is only one node returned by PhysicalView.createNodesForProject and this node is not a project dir node.

Guys, a sarcastic comment follows: Should you write a unit test to show what is wrong and what the correct outcome should be, we would not have to speculate about the implementation and whether it works or not.

(In reply to comment #8)
> without this change original node will be replaced by
> Node.EMPTY in the case there is only one node returned by
> PhysicalView.createNodesForProject and this node is not a project dir node.

Confirmed. I will write a test covering this and try to figure out how to resolve the conflict with lazy projects in ProjectsRootNodeNotRecognizedTest.

core-main #47b6a1a5210d

Integrated into 'main-golden', will be available in build *201105120000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/47b6a1a5210d
User: Jesse Glick <jglick@netbeans.org>
Log: #197864: do not force a project to include its project directory in a generic source group.