Community
Participate
Working Groups
Build Identifier: I20100608-0911 As of Eclipse 3.6, whenever I try to open with the WTP XML editor any file whose extension or filename does not match the XML content type, I get the error: "Unsupported content type in editor. To associate file extension with a supported content type, please see Content Type Preference Page" and then just a basic text editor is opened. Note that this happens even with some of child content type of the XML content type, such as the "Feature Manifest File" or "Product Configuration File" content types. Fresh Eclipse install and workspace. Reproducible: Always Steps to Reproduce: 1. Get some xml file. Rename the extension to .xxx or anything else that does not associate to the XML content type 2. Open context menu on file > "Open With" > XML editor
XML Editor is associated with contentTypes, and those contentTypes are further associated with fileextensions.If your fileextension doesn't match with any of the above assocaited fileextensions, then it will not be opened in XMLEditor.
(In reply to comment #1) > XML Editor is associated with contentTypes, and those contentTypes are further > associated with fileextensions.If your fileextension doesn't match with any of > the above assocaited fileextensions, then it will not be opened in XMLEditor. Is this really the intended behavior for the editor? Any other Eclipse editor i've tried before (including the XML Editor before Eclipse 3.6) allows opening files that do not match the editor content type. Why would the XML Editor be different? (Especially considering one is much more likely to encounter a file with XML content but with a filename that do not match the XML content type, than for example a Java file with a filename that does not end in ".java".)
(In reply to comment #2) > (In reply to comment #1) > > XML Editor is associated with contentTypes, and those contentTypes are further > > associated with fileextensions.If your fileextension doesn't match with any of > > the above assocaited fileextensions, then it will not be opened in XMLEditor. > > Is this really the intended behavior for the editor? Any other Eclipse editor > i've tried before (including the XML Editor before Eclipse 3.6) allows opening > files that do not match the editor content type. Why would the XML Editor be > different? (Especially considering one is much more likely to encounter a file > with XML content but with a filename that do not match the XML content type, > than for example a Java file with a filename that does not end in ".java".) Ok , you when you get "Unsupported content type in editor. To associate file extension with a supported content type, please see Content Type Preference Page" Click on Content Type Preference Page , content type preference dialog will pop up.Expand text node, under that click on xml node.You can add your file extension here( *.xxx etc) .Now you will be able to open it with no problem.
(In reply to comment #2) > Is this really the intended behavior for the editor? Any other Eclipse editor > i've tried before (including the XML Editor before Eclipse 3.6) allows opening > files that do not match the editor content type. Why would the XML Editor be > different? (Especially considering one is much more likely to encounter a file > with XML content but with a filename that do not match the XML content type, > than for example a Java file with a filename that does not end in ".java".) It's an architectural limitation of the editor and its frameworks, one we'll be looking at removing over the next year.
*** Bug 328210 has been marked as a duplicate of this bug. ***
*** Bug 333304 has been marked as a duplicate of this bug. ***
As Nitin mentioned, this is one we're going to be exploring.
*** Bug 327016 has been marked as a duplicate of this bug. ***
*** Bug 367696 has been marked as a duplicate of this bug. ***
Is any workaround for this issue? It is very hardly to use eclipse without having this feature, as there are a lot of xml-files with any extension. For example, I could have erb-template in xml-format, but I definitely can't change its default mime-type association as erb-template could be any mime-type, actually.
No update from the team in over 18 months? This change broke functionality that users relied upon, to be so silent on this issue leaves a bad impression of the WTP team.
(In reply to comment #10) > Is any workaround for this issue? It is very hardly to use eclipse without > having this feature, as there are a lot of xml-files with any extension. For > example, I could have erb-template in xml-format, but I definitely can't > change its default mime-type association as erb-template could be any > mime-type, actually. The workaround has been in our FAQ for years at this point. I've placed its URL in the URL field to make it easier for you to find. I'm having a little trouble parsing the second sentence. (In reply to comment #11) > No update from the team in over 18 months? This change broke functionality that users relied upon... That's incorrect. This has been an architectural issue dating back to the creation of WTP because of our pervasive use of the Platform Content Type system. It can always be handled better, and it's already been improved compared to WTP 0.7, but there's always the question of priorities with insufficient resources to do EVERYTHING we want to accomplish. In the case of comment 0, this is a matter of our IDocument implementation not yet passing _all_ of the platform's text tests and causing them to, understandably, not want to use our (required) implementation with their manifest editors. When we pass those tests or rearchitect things so we no longer require our own implementation (as we'd hoped to when I mentioned it in comment 4), that particular situation will be resolved--and possible this entire defect.
Created attachment 228921 [details] Screen shot showing the workaround isn't working in 3.8 In Eclipse 3.8 the workaround is no longer working for me. This screenshot shows that *.target has been added to the XML content type in Preferences, but when choosing Open with... > XML Editor I still get the Unsupported Content Type message. Same happens for some other XML files with non-xml extensions, such as .product and .launch
I was not aware about this bug (but was very well affected by the strange behavior) until recent discussion on the cross project mailing list. Can we please have an assessment how much effort is needed to simply open the editor with given file, independently if its content type registered as "xml" or not? (In reply to Rakesh from comment #1) > XML Editor is associated with contentTypes, and those contentTypes are > further associated with fileextensions.If your fileextension doesn't match > with any of the above assocaited fileextensions, then it will not be opened > in XMLEditor. WHY??? Just assume a default xml content type for "unknown" file extensions and if this is not working, report "Failed to parse xml on line <XYZ>" error. There are so many "custom" file extensions for xml files so that this "Unsupported content type in editor." error is not of any help for users. I'm not going to register 10+ possible file extensions each time I create a new workspace. The tooling should just try to parse whatever user gives and see if it works or not.
(In reply to Andrey Loskutov from comment #14) > I was not aware about this bug (but was very well affected by the strange > behavior) until recent discussion on the cross project mailing list. > > Can we please have an assessment how much effort is needed to simply open > the editor with given file, independently if its content type registered as > "xml" or not? We've required our own implementation of IDocument since the beginning, and have registered a document factory for the supported content types in that time. As I mentioned in comment 12, our implementation isn't 100% API compliant, so the platform has declared its own document factories for its various manifest file content types and *.target, and they're in the right on that one. I've pushed a smoother version of the workaround to master, but it doesn't change any of these fundamentals. Long term, we have to be able to operate properly off of whatever IDocument implementation the editor is given. It's a huge amount of work, and largely only applies to letting you open files in the XML Editor that already have editors of their own, and the case in bug 434610.
