Bugzilla – Full Text Bug Listing
| Summary: | [Manifest Editor] Opening plugin.xml then Manifest.mf no longer shares same editor | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Nick Edgar <n.a.edgar> | ||||
| Component: | UI | Assignee: | PDE-UI-Inbox <pde-ui-inbox> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | 7elw95btwiuegh2, baumanbr, caniszczyk, cgold, daniel_megert, eclipse, emoffatt, jeffmcaffer, john.arthorne, markus.kell.r | ||||
| Version: | 3.2 | ||||||
| Target Milestone: | 3.4 M1 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 2000 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Nick Edgar
Problem #1: manifest.mf and plugin.xml right. this got broken when we did the Java search participant work. If you search for a Java class and it has references in both plugin.xml and manifest.mf, the annotation model on the source page(s) gets pretty confused and start showing ranges/annotations for one source page on the other. Problem #2: build.propertiees and plugin.xml This was always a problem since build.properties appears as part of both the plugin and feature editors. So a separate standalone is bound to build.properties. *** Bug 137029 has been marked as a duplicate of this bug. *** *** Bug 139543 has been marked as a duplicate of this bug. *** *** Bug 145038 has been marked as a duplicate of this bug. *** *** Bug 150900 has been marked as a duplicate of this bug. *** Created attachment 46417 [details]
org.eclipse.pde.ui.patch
give this a whirl
chris, see comment 1. It explains what scenario your patch would break. If you're talking about the separate issue... what do you expect when a build.properties editor is opened first? I'm talking about this:
>this got broken when we did the Java search participant work.
>If you search for a Java class and it has references in both plugin.xml and
>manifest.mf, the annotation model on the source page(s) gets pretty confused
>and start showing ranges/annotations for one source page on the other.
*** Bug 158992 has been marked as a duplicate of this bug. *** Chris' patch is actually good, but it breaks the Java search participant work. In fact, that's what we originall had but we purposely broke it because of that. However, I just tried it on RC1, and the search participant does not get severely broken as it once did. The annotations are just missing on the plugin.xml source page of a plug-in if there are hits on both the manifest.mf and plugin.xml source pages. I think this is the lesser of the two evils now. We should fix the editor opening issue and let Search worry about the annotations thing (bug 188334) Thoughts? wow, what an amazing patch that it can be applied nearly a year later. That must be an award winning programmer ;-) I too agree it is the lesser of two evils (I personally don't use the java search to find things in the plug-ins and Manifest). Since we get annotations in the Manifest but not plugin.xml, I was wondering if some how we could reverse the (search) order and show annotations in the plugin.xml and not the Manifest? I figured most users would probably match a class from an extension than from the Manifest. Just a thought (if it can even be done). *** Bug 189927 has been marked as a duplicate of this bug. *** *** Bug 177793 has been marked as a duplicate of this bug. *** Fixed. The attached patch assumes the manifest files are at the root of the project, and we should be flexible on that front. We just need to make sure that the build.properties/plugin.xml/MANIFEST.MF are colocated correctly. *** Bug 198197 has been marked as a duplicate of this bug. *** |