This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 53369 - New method FileOwnerQuery.getMarkedExternalOwner
Summary: New method FileOwnerQuery.getMarkedExternalOwner
Status: NEW
Alias: None
Product: projects
Classification: Unclassified
Component: Generic Infrastructure (show other bugs)
Version: 4.x
Hardware: All All
: P2 blocker (vote)
Assignee: Tomas Stupka
Keywords: API
Depends on:
Reported: 2005-01-13 17:42 UTC by Jesse Glick
Modified: 2014-05-12 13:09 UTC (History)
1 user (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2005-01-13 17:42:31 UTC
We are considering revising the recommendations
for handling of external source roots in E, to be
more predictable at runtime, consistent across
project types, and user-friendly. The proposed
rules include

1. GUI should never permit a project to be created
with sources already owned.

2. GUI should never permit a project to add source
roots which are already owned.

3. Register your external roots when opening (or
adding a new root while open), unregister when

4. If a root is already registered to someone else
when opening, cancel the override of its
registration, and issue a warning in the GUI.

The rules seem to require an additional API method
to be properly implemented in some corner cases.
Full discussion:

I think this [rule #4] might require an API
addition. The problem is how exactly you check
ownership. You can simply check FileOwnerQuery,
but there might be cases where you have a project
with some subdirectories which you want to be
owned by some other project (which does not
contain those subdirectories inside its own
project directory), where you want the new project
to register an external source root underneath the
old project's main dir when it is opened.
Supporting this scenario is not much fun, since it
means that FOQ would change results upon opening
the new project, which could cause weird effects,
if you had already opened files from the affected
subdirectory; but it was supported in 4.0 and I am
reluctant to break that. As an example, consider
the editor module:

+ editor
+-+ libsrc
| |
| +-+ org [...]
+-+ lib
  +-+ nbproject [...]

Here editor/lib/nbproject/ specifies


meaning that editor/lib wishes to own
editor/libsrc. Therefore the editor project owns
all of editor/ minus editor/lib/, editor/libsrc/,
and other nested projects.

This currently works if editor/lib has been opened
in the GUI to begin with, since editor/libsrc is
an external source root, and FOQ handles it
correctly. Currently it even works if editor is
opened first, then editor/lib, so long as you do
not try to open files from editor/libsrc until
editor/lib has been opened.

If we adopt the change in #4 in the simple way, it
would be impossible to open editor/lib (with or
without editor already open), since the NBM
project type would reject the attempt to mark an
external root already owned by editor. If however
FOQ could report that editor/libsrc is only
"owned" by editor insofar as it is under the
editor/ tree, but is not a project directory
itself and is not already claimed directly as an
external root, then the NBM project type could
permit editor/lib to be opened and claim
editor/libsrc, leaving the behavior the same as it
is today (i.e. OK so long as you did not open
files from editor/libsrc before). The API change
would be something like

public static FileObject

which would if called on editor/libsrc return null
unless editor/lib had been opened. The pseudocode
in #4, when opening $project, would then be:

foreach external-root $r in $project
  if FOQ.gMEO($r) == null && PM.findProject($r) ==
    FOQ.mEO($r, $project, TRANSIENT)
    warn "$r already used by another project [...]"

I know this is a somewhat unusual scenario but it
can occur and should be handled properly. Note
that the same API call would be needed in rules #1
and #2: it is permissible to add an external
source root which is "owned" by another project so
long as that root is not an actual project
directory nor claimed as an external root by
another project, since after claiming it for the
new project everything will be in order.

Method implementation would be trivial and pose no
compatibility issues: a simple Map lookup in
Comment 1 Jesse Glick 2005-01-13 17:43:31 UTC
Desired for E if possible (yes I know it is late, but this just came
up) - reviewers please comment.
Comment 2 Jesse Glick 2005-01-18 19:07:25 UTC
Is this issue especially important to J2ME developers or anyone else?
If not, it would probably be best to skip this for E and leave for F.
Adding FOQ.gMEO should be simple, but to be really useful

1. The API of ReferencesHelper would probably need to be enhanced to
support (easy) deregistration when the project is closed.

2. Most or all project types should actually implement the new rules,
which would take some work.

Please comment.
Comment 3 Adam Sotona 2005-01-20 10:29:09 UTC
Technical comment:
J2ME project as well as J2SE project use SourcesHelper to register the
source roots.
Current implementation of SourcesHelper does not allow repeated
registration nor any unregistration.
J2SE project use delegation to a SourceHelper instance that is newly
created after any change in source roots without any unregistration
(so all previously registered roots remain registered forever).

If this behavior will stay for 4.1 J2ME project type has no other
option than steal ownership everytime it is possible without any
respect to all previous registerations, to prevent IDE state
equivalent to a deadlock.
Comment 4 Jesse Glick 2005-01-20 16:28:56 UTC
I think the status quo has to be kept for 4.1 due to lack of time to
properly develop, test, and use a new API (mainly in SourcesHelper).
There is simply not enough people to work on this right now, even if
we did not have feature freeze. Please continue to use whatever
workaround you had been using before.
Comment 5 Jesse Glick 2005-03-10 14:59:18 UTC
Not for immediate consideration by API reviewers, unfortunately.
Comment 6 Antonin Nebuzelsky 2010-03-29 14:10:04 UTC
Change of default owner.