Community
Participate
Working Groups
3.4 M6 This is a feature request (for 3.5 or beyond). I am not sure which JDT component it belongs in - perhaps it spans several. It may require support from Platform-CVS in order to discover which repository a project is in. It may require metadata support to determine which project an external class is in. I have no idea how difficult all of this might be, but I think the feature would be cool and useful. The feature is this: If I start typing in a .class file editor, I would like Eclipse to find and load the corresponding java source from a repository (or source jar or source folder) for me. The best way to describe this feature is to walk through a use case: - I discovered, using the SWTSpy tool, that an Eclipse class named FormText (org.eclipse.ui.forms.widgets.FormText) needed an accessibility change - I added all plugins to Java search, clicked Open Type, and opened FormText.class - I looked through the code and saw the lines of code that needed to change - At this point, I wanted to just make the change, test it, and submit a patch - I began typing, but of course, FormText.class is not editable The feature I would like to see begins right when the user types that first keystroke in a .class file editor. I would like Eclipse to determine whether or not the source for this class is in a repository and if so, prompt with something like the following: "Load org.eclipse.ui.forms.widgets.FormText.java: [radio] project xxx in repository dev.eclipse.org:/cvsroot/eclipse [radio] D:\eclipse\plugins\org.eclipse.ui.forms_3.3.100.v20080303.jar OK Cancel" And then either load the project, or fetch the java fila from the source jar. One reason that this feature would be useful is that it is often difficult for a user to determine exactly where the source is. For example, one might expect to find a class named org.eclipse.ui.forms.widgets.FormText in a project named org.eclipse.ui.forms, but this is not the case. I do not typically want to have all of the source code for Eclipse in my workspace, and since I do not know which project the source for FormText is in, I am stuck scrolling through the Eclipse repository and guessing, or asking someone who might know.
(In reply to comment #0) > For example, one might expect > to find a class named org.eclipse.ui.forms.widgets.FormText in a project named > org.eclipse.ui.forms, but this is not the case. I sometimes hit this problem too. I usually use 'Open Type' again and then just type the name of the class and look at the dialog's status bar to see which jar it's coming from. Alternatively, I'd use 'Link with Editor' and just scroll up to check the jar that way.
Link with Editor didn't work for me at first, because I had some filters on. I finally turned on the "Breadcrumb", which shows the jar. But the jar name doesn't help - it is: D:\eclipse\plugins\org.eclipse.ui.forms_3.3.100.v20080303.jar And if I link with editor and scroll up, I see that the jar is in a project called "External Plug-in Libraries". This still doesn't tell me which project FormText is in.
(In reply to comment #2) > Link with Editor didn't work for me at first, because I had some filters on. Yes, I'm not a fan of that filter myself either. > I finally turned on the "Breadcrumb", which shows the jar. > > But the jar name doesn't help - it is: > D:\eclipse\plugins\org.eclipse.ui.forms_3.3.100.v20080303.jar True, there is, after all, nothing stopping you from creating a project named 'A' that contains a bundle named 'B'.
See also bug 148407.
This is also one of my favorite feature requests for 3.5. I want to define actions that replace a binary project into a source project and vice versa. If have such actions, we can implements several interesting features as the one you just described. Another one would be for refactorings when the realize that a refactoring also need to change references in a binary project, it want to offer to 'check out' the binary project first. The actions themselves can't be implemented by JDT, we lack the knowledge about repositories, or where to find the binary. So JDT, or LTK or even platform.resources can define extension points. PDE or Maven have more information and can provide an implementation.
I too find myself searching for the correct CVS location for a particular type...this would help during bug triage where I many times have to redirect a defect based on a call stack. I'd also -love- to see the 'type to check out' UI. I long for the day where my regular workspace is -empty- except for those files that I've changed (ok, perhaps this is a bit too much to expect but I can dream can't I...;-).
There's a slight error in my use case: org.eclipse.ui.forms.widgets.FormText is in fact in project org.eclipse.ui.forms - I just somehow overlooked it yesterday. I realized this while talking to DJ today, who mentioned that although there is nothing that forces a jar file name to be anything in particular, in Eclipse the jar file names are generated from plugin names during the build process. So I had another look for the "missing" file in the repository, and found it. If source loading was automatic, this type of user error wouldn't occur. ;)
