Why can't two projects share a source root, even if only one is open?
Numerous aspects of the NetBeans UI rely on being able to offer actions, editors, and so on for files which are part of a specific kind of project. Generally speaking, these offerings are available whether the owning project is opened or closed - so you can freely work with dependent projects in Favorites, jump to library sources using Ctrl-B, etc. The list of open projects controls what is displayed in the Projects tab and also affects the scope of what Go to Type etc. will list, but has little deeper meaning.
If more than one project claimed to own a single file, none of this could work because it would be ambiguous what features to offer for the file. For example, assuming you have no "main project" set, F11 will just build the project corresponding to the selected file (e.g. whatever editor tab has focus). This relies on there being only one such project.
Some other IDEs strictly divide the world into what is open in a "workspace" and what is not, which has certain advantages but also produces a degree of inflexibility when working with loosely coupled sources.
In the case of Java source roots, the parser (used to build the code completion index and so on) also expects to be able to use a single set of javac options for the whole tree, and compile it as a unit. (Past experiments with eliminating this restriction turned up intractable performance and semantic problems.) This single-pass parse would not work if multiple projects claimed various subsets of the tree, since they might declare different compiler flags.
What is the recommended approach?
Refactor into subprojects
If you are referring to plain Java sources and dependencies, the recommended approach is to factor out the common classes into a library project with an independent source tree, and then declare dependencies on it from various client projects.
(Regardless of the IDE being used, this better enforces what may otherwise be implicit rules about what is permitted to depend on what, and facilitates separate compilation.)
The details will depend on the project type you are using:
- IDE-managed Ant: create the subprojects, and just use Add Project to manage dependencies
- freeform Ant: edit your build scripts, and make sure Output Directory is specified
- Maven: create a POM project containing several jar projects and set up dependencies
For a source tree which for historical or other reasons cannot be moved into a dependency-based "forest" (e.g. you use CVS and cannot tolerate loss of file history after a move), it is best to leave the tree under the control of a single project.
Note that run configurations (the combo box in the toolbar) may be useful if there are many entry points; see FaqTwoMainClassesWithArguments.
If you only ever work on a small subset of the tree and wish to avoid seeing (and compiling) the rest, FaqExcludes may be helpful.
If you are a Unix-only shop and your VCS of choice can handle it, it may also be possible to use symlinks to create NetBeans project shells which just link into a monolithic source tree. E.g.
src/ src/com/ src/com/mycom/ src/com/mycom/common/ src/com/mycom/common/Lib.java src/com/mycom/app1/ src/com/mycom/app1/Main.java (depends on com.mycom.common.Lib) src/com/mycom/app2/ src/com/mycom/app2/Main.java (depends on com.mycom.common.Lib) netbeans/ netbeans/common/ netbeans/common/nbproject/ (project.xml etc.) netbeans/common/src/ netbeans/common/src/com/ netbeans/common/src/com/mycom/ netbeans/common/src/com/mycom/common -> ../../../../../src/com/mycom/common (similarly for app1 and app2)
In this case be sure to only open files through the symlinks. For example, do not use File > Open and browse to src/com/mycom/common/Lib.java; open it as netbeans/common/src/com/mycom/common/Lib.java.