Jesse, I'm moving project infrastructure  base freeform issues to you.

No longer feasible for E.

is this something we want to do for 6.0?

I don't think this is relevant anymore. please reopen if you disagree.

wf

I do think we need to rework our handling of external roots. I don't know if these particular suggestions are the right
approach.

Please reevaluate. The current behavior is known to cause serious problems for JDK developers, who have multiple
projects using the same external source root.

To reproduce:

1. Run IDE on a fresh user dir.

2. Open Project, and browse to the make/netbeans/ subdir of the http://hg.openjdk.java.net/jdk7/jdk7/langtools repo.

3. Select the different project items in turn, but open "compiler".

4. Move the selection around in the Projects tab over source files and watch the Main Window title. Sometimes you can
see non-"compiler" projects considered "selected" now.

5. Otherwise, browse under "Build files" and select e.g. "javap" under "netbeans". Now go back and select some source
files (in editor or Projects) - you will see "javap" in the main window.

The patch I will attach to freeform projects is simple seems to cure the problem: external source root associations are
done predictably when the project is opened. If more than one project is opened and they all claim the same root, the
last to be opened "wins", which is predictable enough.

An alternate fix would be for FileOwnerQuery to collect all projects which claim to own a given external root, giving
preference to the open project if just one, else the last to be registered. But I prefer the simplicity and
predictability of this patch (which would of course also need to done in other project types).

Created attachment 73691 [details]
Suggested patch for freeform project type

The proposed patch does not seem correct to me - I think it would cause serious regressions. For example, consider
projects A and B. A is opened and depends on B. B is a freeform project, is not opened (i.e. its OpenProjectHook was not
called) and has external source roots. After the patch, it seems that no project based query (ClassPath,
FileEncodingQuery, etc.) will answer correctly for the external source roots. This can result into incorrect error
badges, data loss (a file loaded and saved using incorrect encoding), etc.

If B has _never_ been opened then it is correct that queries on B's external source root will not report any project
ownership. If you have ever opened B, then the IDE will remember its association. The same is already true in case b.jar
is externally located. I consider this behavior preferable to the current behavior whereby an external source root may
be silently assigned to a project you have never even opened, which is known (not just hypothetically) to cause serious
problems.

A possible intermediate solution: besides the (now incorrectly-named) EXTERNAL_ALGORITHM_TRANSIENT, introduce e.g.
EXTERNAL_ALGORITHM_CONFIRMED. The behavior would be identical, except that a _CONFIRMED registration would trump a
_TRANSIENT registration: just keep a WeakSet<URI> listing external roots whose ownership has been confirmed, and in
markExternalOwnerTransient, if the URI is in this set and _TRANSIENT is called, then do nothing. Then change project
types to register _TRANSIENT eagerly as now, and then _CONFIRMED upon opening.

Well, but if B does not work because it was not opened yet, it seems to break the basic principle that the projects
should behave in the same way regardless they are opened or not. This seems to me like quite confusing behavior.

1. It is already the case that you need to open a project at least once in case its build artifacts are externally
located. Otherwise the IDE cannot possibly know where the project is!

2. You only need to open the project _once_ (in a given userdir) for the IDE to know about it.

3. I should point out that java.source already fails to correctly scan nonopen projects (even without external roots):
issue #136522, in which you said that support for non-open projects was "best-effort only".

That said, EXTERNAL_ALGORITHM_CONFIRMED would I think address your use case while fixing the OpenJDK problem. I could
prototype and test it (against langtools) if there is interest.

I have nothing against _CONFIRMED. Also, it is true that the external source roots do not work very well now (and your
statements are correct). I only think that the attached patch makes the situation even more unpredictable (for the
user), and that certain things that work today would stop to work after the patch.

Created attachment 73836 [details]
Add-on patch using _CONFIRMED

looks generally ok (both as concept and implementation)
only i'm a bit concerned about the backward compatibility and the way how projects that use the new method will coexist
with those that didn't upgrade to CONFIRMED level on project opening.
Bot it could be just nitpicking, the relevant project types are few.

"I'm [...] concerned [...] how projects that use the new method will coexist with those that didn't upgrade to CONFIRMED
level on project opening" - well, in the unlikely case that a project of old type claims the same external source root
as a project of new type, this just means that if you open the new-type project, close it, then open the old-type
project, the source root will still be associated with the closed project - which is what happens already, i.e. not a
regression. Not sure if there are other cases we're not thinking of.

*** Issue 58058 has been marked as a duplicate of this issue. ***

Change of default owner.

Probably 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