Community
Participate
Working Groups
Open Type allows you to open your own "real" .java resources, or, .class files from external libraries with attached source. But, if your external library contains something else, e.g. an XML schema, plugin.xml, properties file, etc., it is difficult to open such library resources. The only "workaround" is to find the JAR in the package explorer, manually select the desired nested resource, and open it. JDT already indexes the .class files in JARs. Why not index the other files too so they can be easily opened, perhaps from the Open Resource dialog? On a related note, .java files in my workspace appear in the Open Resource dialog, but I often want to open binary types not in my workspace. If these were spoofed into the Open Resource dialog, we'd be on the way to a single, extensible, Open... dialog. see bug 122327. Oh, and the actual problem is that sometimes I'm opening XSD, XML, or PDE editors, and sometimes I'm opening external java types, and I don't want to have to think about which before I bring up the dialog. I find that I've typed the name only to realize the I've opened the wrong dialog. Anyway, the scope of this bug is just that non-.class files (that exist on the "classpath"), and that the index feed into some way to open those files. I'm hoping that this enhancement could be implemented within JDT, providing a test scenario for bug 122327. Rather than the opposite (JDT can't proceed without 122327).
I agree that this is a problem. I guess we could do it in two ways: a. Extend the Open Type dialog to also show resources on the class path b. Extend the Open Resource dialog to allow participants to provide their own storage elements ('editor inputs') to appear so they can be opened. The first one might be easier as it could be done in JDT alone, but it 'Open Type' is the wrong dialog. It would rather become an Open Java Symbol dialog, with fields methods etc. That would be very hard again as our search is not optimized for this. So I would think b would fit more. I would move the request to platform.ui. We have similar open requests with searching for text in files in archives. There have been discussion of allowing to mount a zip (see bug 137879) so that its content can be accessed as resources
> The first one might be easier as it could be done in JDT alone, but it 'Open > Type' is the wrong dialog. It would rather become an Open Java Symbol dialog, > with fields methods etc. I didn't understand this part. Why would fields and methods be in the Open "Something" Editor dialog?
I wanted to say that if we add resources to the 'Open Type', it would more become an 'Open Everything'. That's not what want.
