Summary: | dot's in content-type id breaks content-type dependent configuration | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] Equinox | Reporter: | Max Rydahl Andersen <manderse> | ||||
Component: | Compendium | Assignee: | platform-runtime-inbox <platform-runtime-inbox> | ||||
Status: | RESOLVED WONTFIX | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | P2 | CC: | david_williams, for.work.things, jeffmcaffer, thatnitind | ||||
Version: | 3.2 | Keywords: | greatbug | ||||
Target Milestone: | --- | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Max Rydahl Andersen
2006-05-01 10:13:08 EDT
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. |