Community
Participate
Working Groups
Build Identifier: Helios detectContentType(IPath location) calls findContentTypeFor with path instead of file name. Platform.getContentTypeManager().findContentTypeFor(input, location.toOSString()); should be Platform.getContentTypeManager().findContentTypeFor(input, location.lastSegment()); Reproducible: Always
Could you attach a test-case, or provide steps where it is failing?
(In reply to comment #1) > Could you attach a test-case, or provide steps where it is failing? Have two content type extensions: a) one using a file extension: *.xml (should be already there if you have the wst plugins installed). b) one using a complete file name, using the same file extension: specific_file.xml If I open my specific_file.xml from within the Eclipse workspace, the content type for b) is selected. If the specific_file.xml is not part of my Eclipse workspace, but is opened as external file, the xml content type is chosen. For me it hurts, because the name of the context menu in the XML editor is a different depending on how I open the editor, since the XML editors derive the name of certain context menus from the underlying content type. In one case my context menu contributions appear, in the other they dont't.
Created attachment 182959 [details] patch Platform's ContentTypeManager expects file name to be last name , since it is expected to be mentioned in extension point and not the full name. I was able to reproduce it with the steps above.
Patch looks good. Thanks.
