Community
Participate
Working Groups
I crated a JS file with some functions. I expanded the source folder node under JavaScript Resources. My functions were displayed. I added new functions(while the node remained expanded). It never updated. I closed and re-expanded the node. Still no update. It only updated if I right-clicked and did a Refresh.
What about when you save the file?
Nope.
Created attachment 169048 [details] proposed patch
Created attachment 169092 [details] updated patch - only updates from resource changes
I get an error when applying your patch. The method getParent() is undefined for the type NamespaceGroup PackageExplorerContentProvider.java /org.eclipse.wst.jsdt.ui/src/org/eclipse/wst/jsdt/internal/ui/packageview line 657
Created attachment 169163 [details] updated patch - includes other files
Applied new patch. No more error. I have verified the fix works.
* Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. For 3.2 we've made the types, functions, and variables in the user's source folders visible under the JavaScript Resources node along with the libraries and containers from previous releases. Previously there was no way of getting an overall picture of the types in the user's sources. Without this fix, the contents of the node representing the user's source folder won't update automatically, rendering the feature pretty much useless. * Is there a work-around? If so, why do you believe the work-around is insufficient? The workaround is to manually refreshing the JavaScript Resources node for the source folder every time a JavaScript file is written to disk. It's not obvious that this would be needed, and while it's the only place where it would be needed, the user's own sources are where these kinds of changes are most expected. * How has the fix been tested? Is there a test case attached to the Bugzilla record? Has a JUnit Test been added? Tested by Chris and I, no JUnit. * Give a brief technical overview. Who has reviewed this fix? Reviewed by Chris. The JSDT content provider method for handling IJavaScriptElementDeltas will request a refresh of the parent node if a compilation unit's contents change and the delta was caused by a file modification. The parent has to be refreshed because, by design, we don't show a node for the file itself in this part of the tree. * What is the risk associated with this fix? Low as it only affects what's visible in the common navigator. Only queuing a refresh when the file is also modified on-disk prevents it from being a performance problem while the contents are being updated in the editor without saving, but it still takes non-zero time to refresh that part of the tree.
if you implement 'equals' shouldn't you implement 'hashcode' too?
Created attachment 169254 [details] Add #hashCode() to ProjectLibraryRoot and NamespaceGroup (In reply to comment #9) > if you implement 'equals' shouldn't you implement 'hashCode' too? Yes.
Committing.
