Community
Participate
Working Groups
I was porting WTP 1.0/Eclipse 3.1 code to WTP 1.5/Eclipse 3.2RC1 and discovered that the following did not work anymore: <content-type base-type="org.eclipse.core.runtime.xml" file-extensions="xml" id="content-type.hbm.xml" name="Hibernate Mapping Content-Type" priority="normal"> where as the following worked (note the id name change) <content-type base-type="org.eclipse.core.runtime.xml" file-extensions="xml" id="hbmxmlsource" name="Hibernate Mapping Content-Type" priority="normal"> Looking at bug#128866 and with comments from David W. this should only occur when I have <?eclipse version="3.2"?> in top of my plugin.xml. I did not have this PI instruction thus it should work. I originally intended to report this against the Platform/PDE guys, but decided to put it here since the content-type is actually deduced for the file when looking in the properties of a file, but none of my completion nor outline code were called. e.g. the following extension points did not seem to be picked up: <extension point="org.eclipse.wst.sse.core.modelHandler"> <modelHandler associatedContentTypeId="org.hibernate.eclipse.mapper.content-type.hbm.xml" class="org.hibernate.eclipse.mapper.modelhandler.ModelHandlerForHBMXML" default="false" id="org.hibernate.eclipse.mapper.handler.hbm.xml"> </modelHandler> </extension> <extension point="org.eclipse.wst.sse.ui.editorConfiguration"> <sourceViewerConfiguration target="org.hibernate.eclipse.mapper.content-type.hbm.xml" class="org.hibernate.eclipse.mapper.editors.HBMXMLStructuredTextViewerConfiguration" /> <contentOutlineConfiguration target="org.hibernate.eclipse.mapper.content-type.hbm.xml" class="org.hibernate.eclipse.mapper.views.contentoutline.HibernateXMLContentOutlineConfiguration" /> </extension>
Thanks Max. We might just have to document this as a migration issue, but it deserves investigation to determine what root issue is and if some "namespace migration" would be possible. I'll take a look.
Looking at bug 128866 comment 15, it's apparent that differing behavior by version only happens for the IConfigurationElement.getNamespaceIdentifier() call. org.eclipse.core.internal.content.ContentTypeBuilder.createContentType() instead calls IConfigurationElement.getContributor().getName(), which is claimed to always return the plugin ID. In ContentTypeBuilder, an id value with dots in it is used verbatim while one without dots gets appended to the contributor name/ plugin ID to create the content type's ID. The name is taken regardless and will always be shown as expected, but we still rely on the ID to load our configurations.
btw. just to be clear, this is not an important issue for me personally/company wise to fix since the solution works on both 1.0 and 1.5. But I would say you should put it in the migration notes as a consequence of PDE strictness. I tried to update the wiki page but could not log in (have contacted the webmaster)
Created attachment 40058 [details] small JUnit test that shows behavior change from 3.1 and 3.2 Can run the test to see both succeed on 3.1, but one fails on 3.2. As Max has discovered and Nitin analysed in 3.1 org.eclipse.testContentType.test.one.two becomes test.one.two in 3.2 (where org.eclipse.testConentType is the plugin id).
Moving to platform for comment. Is this "migration" issue something you've anticipated? I'm not sure how big an issue it will be "in the community", but, you might want to help transition, by using the <?eclipse 3.2?> trick as used in project natures? (see bug 128866) Thanks BTW, its not a problem for use in WTP (gee, I guess we used the spec for once? ... by accident? :) ... and sounds like Max is willing to migrate to "use no dots" in content type name. But, you'd at least want to document in migration guides., I'd think.
FYI, I did make note of this in our WTP adopter migration guide, at http://wiki.eclipse.org/index.php/New_Help_for_Old_Friends Thanks Max, and Nitin, for reporting and investigating. I'm sure it'll save others a lot of time rediscovering it.
so why is this one not marked a greatbug ? :)
I think both Max Andersen and David Williams deserve T-shirts for figuring out this one. You are right; this is similar to the bug 128866 in the sense that we didn't expect people to use dots in the IDs. Unfortunately, processing of the content type IDs happens at a different place and the <?eclipse version> tag has no effect on this attribute. The documentation specifies that no "dots" are allowed in ID: http://help.eclipse.org/help31/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/extension-points/org_eclipse_core_runtime_contentTypes.html but it was no enforced. Because: - this is rather late in the development cycle (RC3) and more than a few lines of code would have to change, and - it works for you now I would prefer to just add a short description to the Eclipse migration guide and don't change the code.
may I suggest you add a warning/error to the plugin.xml validation ?
There are different concerns for the validation of different elements. For the extension points, validation rules were relaxed in the bug 135976. For the extensions and content types, to me, it doesn't seem to make sense to add validation at this point - after all, we *are* allowing dots in the IDs now. If anything, validation rule could be added to 3.1 stream, but that would be a bit overkill. Just to clarify: let's say you had an element with ID of "my.Point" in the "org.plugin" plugin. In 3.1, the qualified name of this element would be "org.plugin.my.Point". In 3.2, the qualified name of this element would be "my.Point" (for extensions and extension points this would depend on the eclipse version attribute from plugin.xml). As you see, you get different results for the qualified name in 3.1 and 3.2. However, in 3.2 "my.Point" becomes a valid ID (however, with a different meaning than in 3.1). In general, we suggest: a) switching to 3.2 format for extensions and extension points; b) use simple names unless there is actually a need for a qualified name.
Just ot be clear here, from the various xml fragments included here, not one of them has an extension id. There are elements that have attributes call "id" but that is not recognized and/or processed by the registry. The only thing that is an actual id is the id attribute of the <extension> or <extension-point> elements.
For the lack of a better term I am closing this as "Remind". The comment 8 describes the situation. The text for the migration doc is recorded in the bug 140075.
Sorry, the bug for the migration doc is actually the bug 140175.
No further work planned here.
