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.
|Summary:||New method FileOwnerQuery.getMarkedExternalOwner|
|Product:||projects||Reporter:||Jesse Glick <jglick>|
|Component:||Generic Infrastructure||Assignee:||Tomas Stupka <tstupka>|
|Issue Type:||ENHANCEMENT||Exception Reporter:|
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 closing. 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/project.properties specifies src.dir=../libsrc 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 [FileOwnerQuery.]getMarkedExternalOwner(FileObject root); 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) == null FOQ.mEO($r, $project, TRANSIENT) else 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 SimpleFileOwnerQueryImplementation.externalOwners.
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.