Community
Participate
Working Groups
I have an installation where I use the XML-Editor provided by the org.eclipse.wst.xml_* features. With that the PDE Manifest Editor no longer works reliably: - Opening a plugin.xml for the first time, the outline view "flickers" a few seconds - Copy and pasting an XML snippet in the plugin.xml source editor tab does not syntax-highlight the new snippet. - Editing the plugin.xml source directly is not immediately reflected in the Extensions tab - Using the Extensions tab to edit a dirty plugin.xml is unreliable. The XML content gets easily distorted. The reason seems to be that the 'org.eclipse.wst.xml.core' plugin specifies an IDocumentFactory that ends up creating the document for the plugin.xml file.
Which build of org.eclipse.wst.sse.core?
These are the wst-plugins in my installation: org.eclipse.wst.common.core (1.2.0.v200908252030) org.eclipse.wst.common.emf (1.2.0.v201003082100) org.eclipse.wst.common.emfworkbench.integration (1.2.0.v200908252030) org.eclipse.wst.common.environment (1.0.400.v200912181832) org.eclipse.wst.common.frameworks (1.2.0.v201003040800) org.eclipse.wst.common.frameworks.ui (1.2.0.v201003111500) org.eclipse.wst.common.infopop (1.0.100.v200805301550) org.eclipse.wst.common.modulecore (1.2.0.v201003100700) org.eclipse.wst.common.modulecore.ui (1.0.0.v201003111730) org.eclipse.wst.common.project.facet.core (1.4.100.v201001201731) org.eclipse.wst.common.project.facet.ui (1.4.100.v201002051957) org.eclipse.wst.common.snippets (1.2.0.v200911120509) org.eclipse.wst.common.ui (1.1.500.v200911190730) org.eclipse.wst.common.uriresolver (1.1.401.v201002140504) org.eclipse.wst.dtd.core (1.1.400.v201001111655) org.eclipse.wst.dtd.ui (1.0.500.v201002262219) org.eclipse.wst.dtd.ui.infopop (1.0.300.v200805140200) org.eclipse.wst.dtdeditor.doc.user (1.0.500.v200904292308) org.eclipse.wst.internet.cache (1.0.400.v201003140147) org.eclipse.wst.sse.core (1.1.500.v201003102131) org.eclipse.wst.sse.doc.user (1.1.0.v200805211530) org.eclipse.wst.sse.ui (1.2.0.v201003092125) org.eclipse.wst.sse.ui.infopop (1.0.200.v200805301545) org.eclipse.wst.standard.schemas (1.0.300.v201002230645) org.eclipse.wst.validation (1.2.200.v201002171918) org.eclipse.wst.validation.infopop (1.0.300.v200806041506) org.eclipse.wst.validation.ui (1.2.204.v200910082242) org.eclipse.wst.xml.core (1.1.500.v201003082046) org.eclipse.wst.xml.ui (1.1.100.v201003082046) org.eclipse.wst.xml.ui.infopop (1.0.300.v200805140200) org.eclipse.wst.xmleditor.doc.user (1.0.600.v200901231300) org.eclipse.wst.xsd.core (1.1.501.v200912170622) org.eclipse.wst.xsd.ui (1.2.303.v201003111758) org.eclipse.wst.xsdeditor.doc.user (1.0.700.v200905182240)
Eclipse Version: 3.6.0 I20100312-1448
To simplify matters - AFAIK all our versions are Helios M6, both PDE and WST.
Is this really a PDE bug, or should it be moved to WST?
(In reply to comment #5) > Is this really a PDE bug, or should it be moved to WST? I am not sure. WST uses a public (however deprecated) extension point to provide a document factory that causes the document for the 'plugin.xml' file to be of class org.eclipse.wst.sse.core.internal.text.JobSafeStructuredDocument. The question is: Is the Plug-in Manifest Editor supposed to work with this document, or does it require, that no other plugin provides a document different to the default document kind org.eclipse.core.internal.filebuffers.SynchronizableDocument? In any way the PDE project should know about this problem, that's why I filed the bug against PDE. More information: * You can use the Helios package 'Eclipse for RCP/RAP Developers (214 MB)' to reproduce the issue. * To work around the issue it is sufficient to override the document factory, you could do that in one of the PDE plug-ins: public class DocumentFactory implements IDocumentFactory { public IDocument createDocument() { return FileBuffers.getTextFileBufferManager().createEmptyDocument( null, LocationKind.LOCATION); } } <extension point="org.eclipse.core.filebuffers.documentCreation"> <factory class="....DocumentFactory" contentTypeId="org.eclipse.pde.pluginManifest"/> </extension>
What does the 'org.eclipse.wst.xml.core' documentCreation extension look like? I.e. what sorts of files does it create documents for? In general it seems dangerous to be creating documents for files inteneded for other editors. >Is the Plug-in Manifest Editor supposed to work with this document, or does > it require, that no other plugin provides a document different to the > default document kind > org.eclipse.core.internal.filebuffers.SynchronizableDocument? Not sure yet...
(In reply to comment #7) > What does the 'org.eclipse.wst.xml.core' documentCreation extension look like? > I.e. what sorts of files does it create documents for? In general it seems > dangerous to be creating documents for files inteneded for other editors. This is the contribution, it is used because the 'Plug-in Manifest' content-type derives from the 'XML' content-type: <extension point="org.eclipse.core.filebuffers.documentCreation" id="org.eclipse.wst.xml.core.documentfactories" name="%Structured_XML_Document_Factory_Extension.name"> <factory contentTypeId="org.eclipse.core.runtime.xml" class="org.eclipse.wst.sse.core.internal.filebuffers. BasicStructuredDocumentFactory" /> </extension>
This behavior is always reproducible: Download 3.6M6, then install the Webtools XML Editors. Try editing any plugin.xml... When "uninstalling" the XML editors, the pde manifest editor works as expected.
We should look at this for M7 or RC* I've had 3 people ping me about this issue today -_-
Removing the milestone, if anyone has time to look for a fix it would be appreciated.
*** Bug 312192 has been marked as a duplicate of this bug. ***
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=312192#c6 for steps to reproduce one of the problems with the "unreliable Extension editor". IMHO this bug is critical because it screws up the whole plugin.xml document and users probably will conclude that PDE is completely unreliable. Was the WST document already utilized in 3.5? If not, maybe overwriting the document factory as suggested by Markus in #c6 might be a acceptable workaround, at least for RC1?
Created attachment 167662 [details] fix Hmm, I though I have provided all the help that's needed to fix this issue. To make that clearer I have converted comment 6 into a patch. The patch ensures that the default document is created for all files with a PDE content-type that derives from the XML content-type. With such a document the editor works as usual. This issue needs to be addressed, it severely affects an important PDE feature.
(In reply to comment #14) > Hmm, I though I have provided all the help that's needed to fix this issue. To > make that clearer I have converted comment 6 into a patch. Thanks for the Patch. >The patch ensures > that the default document is created for all files with a PDE content-type that > derives from the XML content-type. With such a document the editor works as > usual. > > This issue needs to be addressed, it severely affects an important PDE feature. +1 for the Patch I tested it with N20100510-2000.
I'm inclinded to use the provided patch, unless there is a better solution (perhaps in WST). Dani, do you know if WST should be doing something else? Seems like this is dangerous for any editor that works on .xml files and does not provide an extension of type "org.eclipse.core.filebuffers.documentCreation" (which is *deprecated*).
(In reply to comment #13) > Was the WST document already utilized in 3.5? To my knowledge we've been using the extension point since it was created; I believe we (WST/SSE) were the ones who requested it. The installation of both PDE and WST is simply far more common in recent releases. (In reply to comment #16) > I'm inclined to use the provided patch, unless there is a better solution > (perhaps in WST). Dani, do you know if WST should be doing something else? > Seems like this is dangerous for any editor that works on .xml files and does > not provide an extension of type > "org.eclipse.core.filebuffers.documentCreation" (which is *deprecated*). As loathe as I am to admit it, we don't have any time to investigate this in WST before the release. Odds are there's some subtle flaw in our IDocument(Extension*)? implementation we haven't caught (similar to our previous problem maintaining IDocumentExtension4's modification stamp that affected the manifest editor's Undo ability), so while I do expect it is our fault, I'd recommend using the patch as well. As for the use of the deprecated extension point, bug 268635 has been open for some time to get us off of it. The ordering of the firing of the additional events that we provide isn't something we can control with an arbitrary IDocument implementation, so we're going to keep using that extension point in the foreseeable future.
It is known since 3.2 (4 years!) that the extension point must no longer be used. Those who do so take into account that they break other plug-ins - like in this case. The only valid use case for using the extension point is if the client is 100% sure to own that content type / extension, which is clearly not the case here. The attached patch will allow PDE to work around the issue for now, hence +1 for RC1.
Applied/Fixed.
I filed bug 312621 to track the removal of PDE's extension dependent on WST.
