Twitter github

Eclipse and Content Type Definitions

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.

  • So what happens when you have two editors that scope to the same namespace and component? 🙂

  • So what happens when you have two editors that scope to the same namespace and component? 🙂

  • Well, obviously that’s a problem. However, the likely hood of those types of collisions are low. Compared to my previous case… where collisions could be high because my content type wasn’t scoped to a namespace AND I used a common root element name.

  • Well, obviously that’s a problem. However, the likely hood of those types of collisions are low. Compared to my previous case… where collisions could be high because my content type wasn’t scoped to a namespace AND I used a common root element name.

  • Robert Konigsberg

    Seems like it’s the same issue that comes along with having other editors that have the same file extension, and is not just limited to xml namespaces. The user gets to choose!

    Ugh, just typing the phrase “xml namespace” makes me shiver.

  • Robert Konigsberg

    Seems like it’s the same issue that comes along with having other editors that have the same file extension, and is not just limited to xml namespaces. The user gets to choose!

    Ugh, just typing the phrase “xml namespace” makes me shiver.

  • Robert Konigsberg

    Does your blog make “smart quotes” out of my dumb quotes?

    String x = “my dumb quotes”;

    Yuck!

  • Robert Konigsberg

    Does your blog make “smart quotes” out of my dumb quotes?

    String x = “my dumb quotes”;

    Yuck!