Bug 208241

Nothing in common with java navigation.
Also I doubt it can work as you described. It does not work even when you have attached sources.
You start with a binary, you translate the binary to source using SFBQ (or generate source file). Now you want to navigate back, the BFSQ translate the source into binary. Now comes the tricky part, the binary is on project cp but in most case it's not owned by project (FOQ), so there is no mapping from cp resource to project. Such a one to one mapping even does not exist, for example rt.jar (classes.jar in your case) is on all project cps, which one should be used? To solve this problem you will need something like ProjectMember or ProjectContext which propagates through IDE features. But for actions which do not start in the project window it's hard or impossible to find some reasonable ProjectContext, so I am not very fond of it.

Probably wantfix.

No "project context" is needed; a project's LogicalViewProvider.findPath could, if passed a generated source corresponding to a class in the project's classpath, select the appropriate subnode under Libraries. (As to the rt.jar case, SiP will just check each project in turn until it finds one which can locate the class.) I do not think the effort to implement such a feature would be justified in actual usage, though.

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

I insist, this is not not an enhancement, this is obviously a usability bug which (among other usability bugs) prevents from  using Netbeans. We're now back to Eclipse. I'm not sure how these "wontfixes" can help Netbeans.

PS
Architectural mistakes are not a reason for not making the product better whether it's simple or not.

What is the actual use case (purpose) for selecting a class file under Libraries in this way? Implementing this would require nontrivial work and I have never heard of another request for it, but it can be reopened if you consider this an important part of IDE workflow.

My use case was that I was trying to find out which jar file of a multi-jar library contains a particular class (starting from a usage of this class in a Java source), and I must say I am not aware of a simple way to accomplish this, as e.g. Find in Projects only searches in sources. From my point of view, the heuristic to just find the first usage if the jar is used by multiple projects (like rt.jar) would be good enough.

But if you say that implementing this would be a significant amount of work, then I don't insist on this being implemented.

(In reply to comment #6)
> find out which jar file of a multi-jar library contains a particular class 
> (starting from a usage of this class in a Java source)

Makes sense.

Would probably need one impl in java.api.common (LibrariesNode) and one in maven (DependenciesNode). Bug #7551 would make it architecturally nicer by letting each Node communicate what it could select.

In reply to comment # 2:
>No "project context" is needed; a project's LogicalViewProvider.findPath could,
>if passed a generated source corresponding to a class in the project's
>classpath, select the appropriate subnode under Libraries.
Which does not work as it selects the source from random project not from the project user has started with.

Here is an example:

Project_1
  -Libs
     -foo.jar
         -A.class
Project_2
  -Libs
     -foo.jar
         -A.class


User selects A.class form Project_2 and opens source. Now he does select in project view.
Which project's LogicalViewProvider should be used? Check each project is clearly wrong as you will end with Project_1/Libs/foo.jar/A.class but should be Project_2/Libs/foo.jar/A.class.

In ambiguous cases Eclipse, for instance, does ugly things  opening/showing/debugging classes from random projects. You can do much more better, I guess. Why just not ask the user? In cases when you're not able to decide on your own, give them option to select.

In this case I would expect a dialog where I could select a project (may be randomly, but this will be my choice and no complains to the IDE).

And more, while the case you mention is possible and in big projects is not very rare, from my practice this ambiguity happens less frequently then the case where the IDE is able to select the right project.

(In reply to comment #8)
> you will end with Project_1/Libs/foo.jar/A.class but should be
> Project_2/Libs/foo.jar/A.class.

So what? Just select Project_1/Libs/foo.jar/A.class anyway. Here I am assuming that both projects are in fact referring to the same JAR (using the same path), so it does not really matter where you browse foo.jar, any more than it would matter which node you double-clicked to open the (associated or decompiled) source file.

>Just select Project_1/Libs/foo.jar/A.class anyway. Here I am assuming
>that both projects are in fact referring to the same JAR (using the same path),
Right.
>so it does not really matter where you browse foo.jar
It does. Lots of people are using the "Select in Project" action to navigate to project. When I want to compile project or change project metadata for some file owned by a project I just call "Select in Project" and it shows me the file in the project. I don't need to search the project among 100+ other projects. In fact I don't use "Select in Project" for anything else, I am opening classes by Go To Type.
If the IDE selects me file in some random project I will do an action on wrong project.

(In reply to comment #11)
> When I want to compile project or change project metadata for some
> file owned by a project I just call "Select in Project" and it shows me the
> file in the project.

And that works fine - for a file actually owned by the project. In this case the JAR is not owned by any individual project, so you could not use that shortcut. Nor can you use it today in these cases; fixing this issue would not change that.

>And that works fine - for a file actually owned by the project. In this case
>the JAR is not owned by any individual project, so you could not use that
>shortcut. 
Unfortunately users are not FileOwnerQuery based. If user sees the jar under the project
it expects that the file is owned by the project. There are several other issues related to this like user has 2 projects with 2 different JavaPlatforms on the top of single JDK. In one project the javadoc (sources) are taken from the second JavaPlatform, etc.
>Nor can you use it today in these cases
Currently it does not select anything
>fixing this issue would not change that.
It will select node under a random project. Which is not the same as selecting nothing.
User may do some destructive operation on such a selected project.

(In reply to comment #13)
> User may do some destructive operation on such a selected project.

Despite seeing the actual project label in the Projects tab, the title of the main window and Properties dialog, etc.? Possible, but I am not convinced this is a good enough reason to reject a sensible enhancement; would not matter for the use case in comment #6, for example.

Comment #9 proposes behaving specially when the choice would be ambiguous, which would mean that (a) no project owns the selection, (b) >1 project returns non-null for it from findPath; or (a) some project owns the selection but does not return it from findPath, (b) >1 other project claims to find it. (See ProjectsRootNode.findNode.) In such a case the IDE could select nothing and print a warning to the status line, or select them all, or produce a list of available projects in a combo box in a dialog and ask the user to pick one to select, etc.

>but I am not convinced this is a good enough reason to reject a sensible enhancement
I've already learned that "simple enhancements" do not work. Simple enhancements sometimes introduce more problems than benefits, for example the HTTP javadoc.

The comment 9 is a solution I've thought about. When the path is ambiguous asking user is the only way how to do the selection right. The UI problem may be when user do selection on java.lang.String while having 100+ projects. The dialog will offer 100 projects to choose from.
Also I still think that there are cases like the Peter's original report which can be done in deterministic way. When I click on the java.lang.String under Project_B  and I (the LibrariesNode) do the open (generate) of the java file I have the Project and I can pass it to the editor to make it deterministic.

When I will some time I will prototype the Project passing among the LibrariesNode and editor.

(In reply to comment #15)
> when user do selection on java.lang.String while having 100+ projects. The
> dialog will offer 100 projects to choose from.

So the user will learn that this is a dumb thing to do. The plausible use cases are when just one project has the library, or when it makes no difference which project you select the node under.

> When I click on the java.lang.String under
> Project_B  and I (the LibrariesNode) do the open (generate) of the java file I
> have the Project and I can pass it to the editor to make it deterministic.

This seems like a bad idea to me.

Fixed jet-main 5d1b82e5768a

Integrated into 'main-golden', will be available in build *201207140002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/5d1b82e5768a
User: Tomas Zezula <tzezula@netbeans.org>
Log: #208241:Select in Projects impl for binary classes in dependencies

This still does not work for me in Maven projects, is it supposed to?

No. Maven has its own fork of libraries nodes, forked in some state and them unmaintained.

(In reply to comment #21)
> No. Maven has its own fork of libraries nodes, forked in some state and them
> unmaintained.

More or less a different codebase given the difference between ant libraries and maven dependencies.

Is this issue supposed to be moved to projects/maven or another one created specifically for maven support?

Create a new one.
But I would not waste a time to do it.
The Libraries nodes should be merged back from all the forks to some stable API in java.project similarly as we did with ProjectProblemsProvider.

Ok, I still filed a new issue #216047 for Maven.