Community
Participate
Working Groups
We do automagic aliasing for when two completely unrelated content types claim to be associated with the exact same file spec. That is bogus, and does not match the user expectation. Explicit aliasing should be supported though. People may want to provide custom content types in the absence of the official content type. For instance, for org.eclipse.core.runtime.properties, we could have: <!-- a placeholder for setups where JDT's official type is not available --> <content-type id="properties" name="%propertiesContentTypeName" base-type="text" file-extensions="properties" default-charset="ISO-8859-1" alias-for="org.eclipse.jdt.core.javaProperties"/>
David, are you guys relying on automagic aliasing for anything? I remember you needed to hijack the XML content type, and you did so by providing another content type for the XML file extension. Is that still the case? That was not the intent for automagic aliasing, and we want to enforce that by having content types explicitly saying if they are supposed to be aliases or not. If none of this make sense, please check: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core-home/documents/content_types.html Section "Conflict Resolution", item #1, and FAQs #7, and #9 to #11.
Oh, nevermind, in the context of bug 80669 I found the information I needed. We are going ahead with this.
Fixed. Released to HEAD.
BTW, having the explicit aliasing is a great idea.
