This should be part of the projects/projectsui module, not openide.
Even the original action was in core, not openide.

OK, back to you I guess. :-) Will presumably also need a new action to
display a file in the Projects tab (if possible).

Just adding Jesse's ideas on the topic:

Currently the buildsys prototype lacks a nice piece of functionality
present in NB 3.6 which is the menu item Window -> Select Document
Node In -> Projects. The behavior should be to expand the project
containing the open document in the Projects tab and select the file
node - in the physical view if it is displayed, certainly, or in the
logical view if that is displayed and it is possible to select the
file node (logical views might not display every file contained in the
project).

Similarly, when you create a new file in a project, it should be
automatically selected in the Projects tab. Currently it is selected
only in the Filesystems tab, which is (as Petr would say) hnusny.

The main problem is that with logical views, this is not as simple as
it was in NB 3.6. The impl of both features in 3.6 is based on a bunch
of rather ugly hacks: for "Select Document Node In" submenu items, the
appropriate Explorer view searches around for the file, relying on the
fact that the node structure follows folder structure; showing newly
created files is also done by the Explorer view, which uses
OperationListener.postCreateFromTemplate to detect newly created files
(yecch). Some implementation options:

1. For the Filesystems tab, probably we don't have to make any changes
- should still work as before. (*If* we continue to display all disk
roots, rather than just physical views of open projects.)

2. For physical views in the Projects tab, we could use the same hacks
as in NB 3.6 for both features.

3. For logical views there is a problem: the Projects tab impl cannot
be sure what the logical view will look like and so it cannot know
exactly where to look for a particular file. One solution would be to
reopen issue #7551 (see my somewhat peevish comments in that issue)
and request direct support in the Explorer (or Nodes?) API. This would
probably mean that the provider of a logical view would somehow mark
the Node's with some finder interface/cookie/etc. which would know how
to traverse the node hierarchy to find a node matching some criterion
- e.g. one having a particular cookie (DataObject is the one of
interest here).
(This would provide a more maintainable solution to #1 and #2 as well
in the case of creating a new file - may be no need to use
OperationListener, since the New file wizard could request the
selection, and this call would go through the APIs and be implemented
by the Projects tab infrastructure in conjunction with the particular
logical view implementation.)4. Or, rather than reopen #7551 and
request general Open APIs support for solving #3, we could keep it
localized to the projects/projectui SPI. I.e. LogicalViewProvider
would be required to supply not only a root Node, but also some way of
finding selections in it, e.g. add a method to LVP
/**  * Try to find a given node in the logical view.  
* If some node within the logical view tree has the supplied object  
* in its lookup, it ought to be returned if that is practical.  
* If there are multiple such nodes, the one most suitable for display
 * to the user should be returned.  
* This may be used to select nodes corresponding to files, etc.  
* The following constraint should hold:  
* <pre>  
* private static boolean isAncestor(Node root, Node n) {  
*     if (n == null) return false;  
*     if (n == root) return true;  
*     return isAncestor(root, n.getParentNode());  
* }  
* // ...  
* Node root = ...;  
* Object target = ...;  
* LogicalViewProvider lvp = ...;  
* Node n = lvp.findPath(root, target);  
* if (n != null) {  
*     assert isAncestor(root, n);  
*     Lookup.Template tmpl = new Lookup.Template(null, null, target); 
*     Collection res = n.getLookup().lookup(tmpl).allInstances();  
*     assert Collections.singleton(target).equals(new HashSet(res)); 
* }  
* </pre>  
* @param root a root node from {@link #createLogicalView}  
* @param target a target cookie, such as a {@link DataObject}  
* @return a subnode with that cookie, or null  
*/
Node findPath(Node root, Object target);

What does everyone (esp. Petr) think? Jano, we need a UI blessing, but
since the situation for the user is so similar to NB 3.6 I don't guess
it needs much discussion. The question is more how it should be
implemented technically.

-J.

Making P2. Either we'll ignore it for D or it will require API change.

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

The API for searching was added. Also the action was implemented for
searching in LogicalView (AKA ProjectTab). There is still no
implementation for PysicalView (AKA FilesTab) See issue #42976 

The API you came up with suffers from a serious flaw (not present in
the API I originally suggested): it prevents the LV from implementing
node renaming how it likes it. Since the node names must be unique
within their parents, you cannot have an arbitrary base name. Directly
affects PackageViewChildren since if you want the renamable name to be
the last component of the package (rather than the full package), you
are out of luck. Cf. also comments in issue #33330.

OK I may change the method to directly return the node. But it is very
likely that the implementayion will work with the names anyway. Or A'm
I missing something? 

Do you see any problem to have it as a cookie. If you want to have it
in lhe LVP. Shouldn't we add something similar intop package views?

If you have the (Node,Object) -> Node variant then you can select the
correct path even if you have e.g.

+ Sources
|
+-+ org.netbeans.api.foo
| |
| +-+ Something.java
|
+-+ org.netbeans.spi.foo
  |
  +-+ Something.java

With the current API you could choose between

1. Making Node.getName return the full package - meaning impossible to
have any other rename behavior than showing the full package name to
the user during a rename.

2. Not working in the above scenario if you e.g. tried to select
src/org/netbeans/spi/foo/Something.java: return value would be e.g.
["src", "foo", "Something"] which is useless.

(In general, using Node.name for describing paths in a hierarchy is OK
in and of itself, *but* it does not work well with other things: (1)
Node.getName() is used as the starting point for a rename if
canRename(), and you cannot differentiate these uses; (2) DataNode
uses the base name without extension as the Node.name which makes it
impossible to distinguish two files differing only by extension. This
is why for Looks, in issue #33330, I suggested a separate method
specifically for persisting and describing paths.)

If you can access the actual node's in the impl of the NPP, can you
have whatever getName/setName you like (to impl rename however you
like), but use getCookie(DataFolder) or similar to determine which
actual package node you want.

"Do you see any problem to have it as a cookie. If you want to have it
in lhe LVP. Shouldn't we add something similar intop package views?" -
not quite sure what you're asking here but one thing I noticed is that
you did not give enough information in PackageView Javadoc for a
project type to know how to find a node inside a package list. With
the current API it is possible to document the code names of the
package nodes and thus the complete structure of the package list, but
this is unpleasant and constrains the UI too much. Better IMHO would
be some way for the project type to get a delegate NPP for a
particular package list (e.g. for "Sources") so that it does not need
to know the internal structure. If PackageView returned a Node, this
could work simply by having it have a NPP instance in its lookup;
since it returns a Children I think you need a separate static API
method in PV to get a singleton NPP which works over package views.

Jo, I understand from the beginning the problem with names. I just
tough it would be nice to have it this way if we already have that
handy method in NodeOp. OK let's wait for looks and getId(). (Not
going to implement that for nodes :-)

Ad) PackageView. Yes this is what I meant I wanted to add some method
into the PackageView which would either do the search in nodes
directly e.g. resolveNode( Children ch ) which would throw
IllegalArgumentException if the Children would not be created by the
PackageView. Would that work?
BTW returning children is probably OK as people may use them under
their special nodes. Or should I change even this.

So what's the resolution should I put the new method into LVP? (It's
interface -> let's what will bereak) or should I leave it in the
node's lookup with the changed signature for searching? (Jarda votes
for the first soution FYI)

Slight preference to leave the method (with new signature) in a
separate interface NodePathResolver, included in the root node's
lookup, and add a factory method to PV which would return an instance
of this interface usable for scanning PVC (on anything else it would
just return null). Maybe some day we could expand the API into a more
general searching infrastructure.

However it would also be fine with me to add the method (with new sig)
to LVP, and add a method to PV like

/**
 * Find a particular node in a package view.
 * @param packageView the return value of some call to {@link
#createPackageView}
 * @param o an object to look for such as a {@link DataObject}
 * @return a node in the package view with that object in its lookup,
or null if no such node can be found
 * @see NodePathResolver
 */
public static Node findNode(Children packageView, Object o);

So the API was changed to have the signature proposed by Jesse.
Resides in LogicalViewProvider. Stiil need to add support method into
the PavkageView.