I came across a bug in PDE recently regarding content types.
For example, let’s pretend you had a xml file like this:
<?xml version="1.0" encoding="UTF-8"?> <scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="Command Provider for Dictionary Service"> <implementation class="org.eclipse.example.ds.ServiceComponent"/> <service> <provide interface="org.eclipse.osgi.framework.console.CommandProvider"/> </service> <reference bind="setDictionary" cardinality="1..1" interface="org.eclipse.example.ds.DictionaryService" name="Dictionary" policy="static" unbind="unsetDictionary"/> </scr:component> |
And this content type extension definition:
<extension point="org.eclipse.core.contenttype.contentTypes"> <content-type base-type="org.eclipse.core.runtime.xml" file-extensions="xml" id="org.eclipse.pde.ds.core.content-type" name="%content-type.name" priority="high"> <describer class="org.eclipse.core.runtime.content.XMLRootElementContentDescriber2"> <parameter name="element" value="component"> </parameter> </describer> </content-type> </extension> |
Looks ok, right? The content type should be associated with files that start with the component tag. Cool! Well, the problem is since Eclipse is open for contribution, someone else can come along and define a “component” format and than you have the problem of your editor associations being messed up. Many bad things can happen.
<?xml version="1.0" encoding="UTF-8"?> <component name="stuff"> <...> </component> |
The fix is to have my content type definition scoped by namespace. This is trivial since XMLRootElementContentDescriber2
supports namespaces.
<describer class="org.eclipse.core.runtime.content.XMLRootElementContentDescriber2"> <parameter name="element" value="{http://www.osgi.org/xmlns/scr/v1.1.0}component"> </parameter> </describer> |
You learn something new everyday.