Bugzilla – Full Text Bug Listing
| Summary: | imported source plugins not picked up | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Jeff McAffer <jeffmcaffer> | ||||||
| Component: | UI | Assignee: | PDE-UI-Inbox <pde-ui-inbox> | ||||||
| Status: | RESOLVED WORKSFORME | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | contact, curtis.windatt.public, darin.eclipse | ||||||
| Version: | 3.4 | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows Vista | ||||||||
| Whiteboard: | stalebug | ||||||||
| Attachments: |
|
||||||||
|
Description
Jeff McAffer
Note that importing as source does not work because it appears that a real plguin project is made and the manifest has all manner of unresolved dependencies so the classes are not found also, all the source is not found in the imported plugin project. Perhaps it was not found correctly in the origin plugin location? Does PDE look for the source plugins when importing plugins with source folders? There were no source folders when I tried this workflow (In reply to comment #2) > also, all the source is not found in the imported plugin project. Perhaps it > was not found correctly in the origin plugin location? Does PDE look for the > source plugins when importing plugins with source folders? There were no > source folders when I tried this workflow > When importing plugins with source, we look for the source in the known source locations, which is defined by the target platform. Importing the source plugin has no benefit, and we were considering filtering them from the import wizard. A different option would be to have the import wizard detect if a source plugin was selected for import and if so add it to the source locations instead of the workspace. The easiest way to do this would be to add the source plugin to the target platform, but perhaps we can add internal hooks to just add it as a source location. as a point of interest, why not just import the source bundle into the workspace and treat it as a source bundle (i.e., as you would if it were in the target). Minimize magic (In reply to comment #4) > as a point of interest, why not just import the source bundle into the > workspace and treat it as a source bundle (i.e., as you would if it were in the > target). Minimize magic We don't want the user to be able to edit this source - it's not something they are developing. It's really just a source attachment (we don't import src.zip for system libraries...). My point here is that I have a bundle. It happens to say that is supplies source. It might do other things. Either way, if I import it then I should just get a bundle project like any other bundle project. Conversely, if I have a normal bundle project with code etc. and add the source markup to the manifest and put source in the bundle, it would make sense (at least to me) that the source be detected and used. In short, I don't see the downside to allowing this behaviour and from function, simplicity and coherence points of view it has upsides. I agree it's just a bunlde, but what happens when someone edits the source? Do we disallow it? Do you expect it to re-build the class files? (I don't think you intend this to work, as the setup would be quite different than a simple bundle project with source code). I think having editable source would be a bad idea - it would give users the idea that they can change it. I think we would have to set it to be read-only to avoid confusion... Especially while debugging, it is easy to end up in "attached" source and make modifications. I would not setup the imported source bundle project as one that has "source" from the JDT point of view. there is no compiling etc going on. It is simply a prjoecgt that happens to have a mess of text files that happen to have Java code and end in .java. The regular bundle source lookup mechanism, if told about these bundle projects because they have the appropriate markup in the manifests, would then see these as bundles and get source from them. Managing it such that the source is readonly is outside my understanding. How do we do that today when the source is in a source folder in the filesystem? Can the same mechanism? (In reply to comment #8) > Managing it such that the source is readonly is outside my understanding. How > do we do that today when the source is in a source folder in the filesystem? > Can the same mechanism? If external source is attached to an archive today, the source is visible when you open the corresponding .class file (i.e. you get a .class file editor which displays the attached source). The .class file editor does not allow editing (is read-only). So, a similar thing would happen here - the .class file editor would open displaying attached source, in read-only mode. (So, I was wrong about the debugging case - this would play nicely). The remaining issue is that there is still a way to navigate to the .java files manually (i.e. open the source bundle, drill down). In this case, a .java file editor will open and allow editing. (Ideally, I suppose that opening a .java file in this case would actually open the corresponding .class file editor - but, I'm pretty sure there isn't any infrastruture for this - since editors are based on file extensions...). Created attachment 105189 [details]
Work In Progress
Some code that I'm playing with that allows workspace bundles to be treated as source locations. Also improve the source location pref page (better icons/text).
Created attachment 105190 [details]
mylyn/context/zip
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. This bug has been marked as stalebug a while ago without any further interaction. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard flag. |