Moreover there could be button in toolbar for this action. Proper toolbar could
be Data toolbar, which now includes Find, Explore from here, Properties,...

It is not feasible to lookup a node for a Java Hierarchy element with the
current API. Since any module may participate in producing nodes underneath Java
source possibly completely restructuring the tree, we need some additional API
to provide navigation through the resulting structure.

*** Bug 8307 has been marked as a duplicate of this bug. ***

I think this could be nice enhancement.

Target milestone -> 3.3

Reassinging to netbeans.org mailing address.

Target milestone -> 3.3.1.

This probably needs to be dealt with more generally at an API level.
Some sort of "node synchronizer" interface needs to be available which
can take a DataObject (e.g.) and select it. Not trivial, esp. when
everything in sight will be a LookNode!

Found API enhancement request.

Created attachment 5239 [details]
ShowInExplorer module

Thank you Svata for allowing me to "host" this very primitive "module" 
in this issue. :-)

More info about it can be found at:
<http://www.netbeans.org/servlets/ReadMsg?msgId=293141&listName=nbuser
s>

Cleaning up before 4.0 planning

Target milestone was changed from not determined to TBD

From what Jesse wrote I would say that this is not Java specific
feature. Shouldn't this issue be moved to OpenIDE.Explorer?

In new projects we have similar problem, see issue 26326.

Sorry, I overlooked dependency on issue 7551. Ignore my previous comment.

Marking as NB4DEV issue; I might be able to solve it given the limited
scope of project explorer views. David, I hope you will forgive me if
I reuse the code from your module.

Feel free to reuse it as it fits you. I found this feature very
useful. I'm using it everyday. 

Reassigning to hie.

i'm changing this to a defect and adding 4.0 as the target.

defect justification: the lack of selection tracking between the
editor and the explorer confuses users feedback substantially; the
degree that the ide uses context sensitive actions compounds the
usability imact of this problem.

it should be something we fix when we introduce projects.

C.f. IntelliJ -- an Editor has an action "Show in" and a list of
(project explorer) views appears. The chosen view is brought to top
and the file is selected in it.

Chris,  please propose some ui for it. Probably 
some menu item, or short-cut and then reassign 
it to proper developer. Thanks

a sufficient solution is to simply have node selection in the explorer
follow on a file/dataobject level the selection in the editor.

this is a one way street though -the editor doesn't follow the
explorer on simple selection -only on double clicking as is now.

"a sufficient solution is to simply have node selection in the
explorer follow on a file/dataobject level the selection in the
editor."

You are joking, right?
You should not mess with user's carefully expanded and scrolled
explorer unless the user express he wishes it.

IMO it will be useful for user to be able to turn on/off this
editor->explorer automatic synchrozniation, or not to do
autosynchronization at all and rather create a short-cut for this action.

hmm. well, i don't think it's as drastic as what Petr is trying to
insinuate. the state of the explorer stays the same (node expansions
and all the rest) the only difference is that the selection moves to
the node that belongs to the file being edited. eclipse has an option
for this (actually, i didn't know it was an option until just now and
had assumed that's just the way things were). 

at any rate, i don't think this as an additional option a la eclipse
is a bad thing.

> node expansions and all the rest
How can you select a node in an unexpanded package?

OK, to be constructive:
Why do I need to select edited file in explorer?
Every time I need this function, it is to do some operation on the
file:
*) Edit file properties
*) Invoke "Override method" (bad example, bad accessibility of this
   function should be solved elsewhere)
*) Rename

Now, If I have explorer *and*  structure view (preferably
autosynchronized this time ;-), but at least tracking focus changes)
the file node may be the root node of the structure view so I can
access the functionality there.

"Why do I need to select edited file in explorer?" - my daily usecase
is following:

FastOpen a java file; do some edits; ...; I need to get to to the
package to open a different file from that package or to browse other
files in that package or subpackage.

Because I'm using FastOpen frequently I do not want the explorer to
expand folders and focus edited file's node automatically.

so going over the feedback here we should, and Jan B suggested, have
this as an option (synch between editor and explorer) and leave the
default not to synch between the two.

does that work?

My opinion (take it or leave it):
You're building on wrong premise:
"the lack of selection tracking ... confuses users feedback"
That is not the problem here. Users are not confused, they just need
from time to time (not *that* often) to find the thing they're just
editing in the explorer.
"from time to time" is like "3 times an hour" or "one burst a day",
but certainly not constantly after each jump from editor to editor.
This is why explicit action was proposed, not autotracking.

I vote for explicit action too.

I've been using the "ShowInExplorer" module for a while, 
and I think it does what most users need. It is enough for 
me, at least.

See issue 35652

*** This issue has been marked as a duplicate of 18856 ***

verifying duplicity.... really cool feature ;)

Reorganization of java component