Community
Participate
Working Groups
RC2: I'm defeated. How do I get to see DiagramImpl in the Type Hierarchy? I've restarted Eclipse with GMF SDK installed to ensure that source is available. No difference. After typing DiagramImpl as the filter there are no options. In the pull down there are strange entries some of which correspond to Working Sets. I'm presuming that something is being 'clever' (where is that paperclip icon?) and restricting types to those 'in my Working Set'. But I can see DiagramImpl in my stack trace so it _IS_ in my Working Set for me even if none of my plugins have a GMF import. Top of the Working Set list is one called "Window Working Set". I've no idea what this means. Is "Window" a verb? Probably not no "...". What is the Window Working Set? Please give me back the behaviour I've had for at least 8 years.
We are talking about the 'Type Hierarchy' view, right? How do you open it? Make sure that it is not filtered (view menu > Deselect Working Set). Is there anything in the .log? Often, when a type is missing, the underlying reason is that it is no longer on the Java build path. Open the 'Problems' view, make sure all problems are shown (view menu > Show > Show All).
Yes. Type Hierarchy View. I've tried Deselect Working Set. The workaround is to create a dummy project that imports the plugin of interest. I vaguely recall, at about M7, an icon in the top right of the "Focus On Type" dialog that seemed to allow all/windowed selection. I can't see it now. I feel that it should be possible to see all types in the plugin registry and workspace. The default setting of all/windowed is debatable, but if the selection is easy and obvious the default doesn't matter too much. Perhaps similar icons to GIT history scope could allow plugins/projects/...mylyn/... scope.
(In reply to comment #1) > Make sure that it is not filtered (view menu > Deselect Working Set). I don't actually understand this. I only ever select a Working Set for searches. Is this leakage of a mylyn task concept? I endeavour to switch this all off because I find it very unhelpful and too often mylyn is associated with broken workspace nightmares. > Is there anything in the .log? Tons, but nothing relevant. Lots of projects are misbehaving at present.
> I vaguely recall, at about M7, an icon in the top right of the "Focus On > Type" dialog that seemed to allow all/windowed selection. I can't see it now. Can you attach a screen shot of that dialog with that icon? Eclipse SDK out of the box does not have an icon in the 'Focus On Type' dialog. If you use Mylyn then this could be the problem. They filter things which it thinks are not relevant. Do you also see the problem if you use our latest Juno RC3 build without Mylyn: 3.8:http://download.eclipse.org/eclipse/downloads/drops/S-3.8RC3-201205310600/ 4.2:http://download.eclipse.org/eclipse/downloads/drops4/S-4.2RC3-201205311500/ ?
(In reply to comment #4) > > I vaguely recall, at about M7, an icon in the top right of the "Focus On > > Type" dialog that seemed to allow all/windowed selection. I can't see it now. > Can you attach a screen shot of that dialog with that icon? Eclipse SDK out of > the box does not have an icon in the 'Focus On Type' dialog. Sorry it's only vaguely recall. > If you use Mylyn then this could be the problem. They filter things which it > thinks are not relevant. I think I've successfully uninstalled Mylyn Wikitext and moved all plugins. Help Installation show no org.eclipse.mylyn.*. On RC2, with no plugins referencing GEF, org.eclipse.gef.EditPart cannot be focussed on. OPen a project that depends on GEF and EditPart can be focessed. Close the project again and EditPart is again unfocussable and the EditPart view is even retracted from the prevailing Type Hierarchy View. > Do you also see the problem if you use our latest Juno > RC3 build without Mylyn: > 3.8:http://download.eclipse.org/eclipse/downloads/drops/S-3.8RC3-201205310600/ > 4.2:http://download.eclipse.org/eclipse/downloads/drops4/S-4.2RC3-201205311500/ > ? I'll try in a couple of days once other RC3s are available.
> On RC2, with no plugins referencing GEF, org.eclipse.gef.EditPart cannot be > focussed on. OPen a project that depends on GEF and EditPart can be focessed. > Close the project again and EditPart is again unfocussable and the EditPart > view is even retracted from the prevailing Type Hierarchy View. OK, what you describe is expected. The IDE only knows types that it can reach through an open project.
But that means I cannot look at types that appear on the stack without creating a dummy project. Really unhelpful, and obscure to workaround.
No sure I understand your need completely. But would Preferences > Plug-in Development > "Include all plug-ins from Taget in Java Search" help?
(In reply to comment #7) > But that means I cannot look at types that appear on the stack without creating > a dummy project. Really unhelpful, and obscure to workaround. What do you mean by "on the stack"?
(In reply to comment #8) > No sure I understand your need completely. But would Preferences > Plug-in > Development > "Include all plug-ins from Taget in Java Search" help? Yes. Not where I would expect to look, and most of the time the narrow project scope is good. It would be nice if this preferencde appeared on the Focus On Type dialog or in the Type Filters.... (In reply to comment #9) > What do you mean by "on the stack"? My use case is that I am developing an org.eclipse.core.expressions.PropertyTester to guard the appearance of a contributed action in third party menus. I am therefore 'running' in third party applications and so while I have no GEF code, my PropertyTester can be 'running' in a GEF application context, so the Debugger view shows me GEF classes on the stack and in the variables view, but I cannot study them.
(In reply to comment #10) > (In reply to comment #8) > > No sure I understand your need completely. But would Preferences > Plug-in > > Development > "Include all plug-ins from Taget in Java Search" help? > > Yes. Not where I would expect to look, and most of the time the narrow project > scope is good. It would be nice if this preferencde appeared on the Focus On > Type dialog or in the Type Filters.... > > (In reply to comment #9) > > What do you mean by "on the stack"? > > My use case is that I am developing an > org.eclipse.core.expressions.PropertyTester to guard the appearance of a > contributed action in third party menus. I am therefore 'running' in third > party applications and so while I have no GEF code, my PropertyTester can be > 'running' in a GEF application context, so the Debugger view shows me GEF > classes on the stack and in the variables view, but I cannot study them. For that scenario, Marcel's hint is the right fix. Note that this is a more general problem. One can also have a launch configuration that has an optional (non-Eclipse) JAR on the classpath, and even if one adds source during debugging, that code won't be available for full inspection because it's not known to the IDE. We would have to create a dummy project in the background that has all the classpath things on the Java build path in order to fully work. I think it's fair enough, that if you want to test such an optional JAR, you load it into the IDE, either by creating the dummy project yourself.
(In reply to Dani Megert from comment #6) > OK, what you describe is expected. The IDE only knows types that it can > reach through an open project. In Bug 437445#3 I am requested to set a breakpoint in org.eclipse.jdi.internal.connect.SocketTransportService.readHandshake(InputStream) How? I cannot find SocketTransportService. There is no org.eclipse.jdi plugin to import. So I Google, discover org.eclipse.jdi is part of jdt, import all JDT projects and problem solved. 5 minutes wasted. IMHO Eclipse should provide a mechanism to find important classes.
(In reply to Ed Willink from comment #12) > (In reply to Dani Megert from comment #6) > > OK, what you describe is expected. The IDE only knows types that it can > > reach through an open project. > > In Bug 437445#3 I am requested to set a breakpoint in > > org.eclipse.jdi.internal.connect.SocketTransportService. > readHandshake(InputStream) > > How? I cannot find SocketTransportService. There is no org.eclipse.jdi > plugin to import. > > So I Google, discover org.eclipse.jdi is part of jdt, import all JDT > projects and problem solved. > > 5 minutes wasted. > > IMHO Eclipse should provide a mechanism to find important classes. The right way is what Marcel and I mentioned. JDT can't help you with that by its own.
(In reply to Dani Megert from comment #13) > > IMHO Eclipse should provide a mechanism to find important classes. > > The right way is what Marcel and I mentioned. JDT can't help you with that > by its own. Marcels approach of changing the PDE preferece has no effect on the type hierarchy. JDT certainly CAN help. You just scan the bundlepath for all classes.
