Bugzilla – Full Text Bug Listing
| Summary: | [Xpand] contentTypes configuration breaks existing projects | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] GMF-Tooling | Reporter: | Sven Efftinge <sven.efftinge> | ||||
| Component: | Core | Assignee: | Artem Tikhomirov <tikhomirov.artem> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | richard.gronback, sebastian.zarnekow, torsten.krohn | ||||
| Version: | 2.1 | Keywords: | helpwanted | ||||
| Target Milestone: | 2.2 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Sven, sorry for the inconvenience. Any idea how to make content type specific to GMF? Few solutions that come into mind are not perfect: one is to look into IMPORT statement, which has nsURI in case of GMF Xpand. However, it won't work for empty templates or templates without an import? Another would be restrict detection to respect project type/nature, although not sure it's valid behavior for a content type detector. I think the best solution would be to remove the content type declaration. A compromise would be to look for the french quotes to determine the real encoding. Although this too would affect M2T/Xpand files, the detected encoding should be correct for all kinds of Xpand files. (In reply to comment #2) Guess, removing content type is not an option. Instead, we should restrict this content type to match specific version of xpt file. > A compromise would be to look for the french quotes to determine the real > encoding. It is possible to detect charset for a content-type based on file contents. I wonder is this solution won't cause any further complications (charset would be correct, but org.eclipse.gmf.xpand content type would be reported for M2M xpt files as well). Recently we've switched to UTF-8 as default encoding for xpand files (bug #191653), although we still recognize files with old (ISO-8859-1) encoding (using ITextContentDescriber). I can add more recognized encodings, if you provide me with specific list. That won't be a very nice solution, though, and the better one would be another ContentDescriber for m2t.xpand project. No more activity anticipated here, leaving as open in case there's a list of encodings to support or anyone willing to contribute a solution (note helpwanted keyword ;)) Switching to UTF-8 doesn't solve anything here. Having GMF installed still breaks M2T Xpand projects in the same way. It's simply a bad idea to register such a contentType for xpand files. I think you really need to solve this for galileo, as both Xpand and GMF will be included. Content type is Eclipse way to describe and identify files and their content. I'd say we should drop it only if there's no other way to deal with the issue, and it looks like we didn't try any other solution yet. I wonder why another content type, with own describer/detection logic, from m2t.xpand project is not a solution here? Basically, we need to answer questions (a) "What's encoding of workspace file" and (b) "What's encoding of deployed resource?". Perhaps, our approach to encoding is not good and we should do it differently, but it works in the honest Eclipse way for question (a) and try-to-be-smart for (b). Alternatives? I'm eager to see a solution, but personally I don't see anything reasonable (except external configuration files, the approach that seems worse than contenttypes). I didn't mean to say that content types are a bad thing in general. It's just because given the special situation we are in, where we have to implementation for the same language, it's problematic to use content types overwriting the encoding. They do affect both implementations. If you would jut remove the encoding part in the content type, both Xpand and GMF users could use the encoding of their choice using the standard mechanism provided by the resources plugin. Currently you have to explicitly set the encoding for each file, because the workspace settings or container settings are overridden by the content type information. Those questions you're raising are not specific to Xpand. That's why there is the possibility to set encodings per resource. At least question (a) can be answered by using IResource API. Created attachment 130369 [details]
Fixes the encoding issue with xpt files.
(In reply to comment #8) I'll look into this once I'm back, next week. Don't think I'm ignoring the bug ;) (In reply to comment #8) > Created an attachment (id=130369) [details] > Fixes the encoding issue with xpt files. > Torsten, why did you remove encoding detection altogether? I see the point for utilizing import statement to reduce applicability of the ContentDescriber (though, I don't think it's quite good), but what's wrong with encoding detection when it's GMF's template? I've updated ContentDescriber to look into IMPORT statement, but unlike the patch, this information is more of a hint kind (though, when m2t.xpand IMPORT is found, ContentDescriber confidently says "No, it's NOT GMF's Xpand"). Otherwise, encoding detection takes place (both when template is definitely GMF's and when it can't be told for sure) With this, hopefully M2T templates would not get GMF's content type. Please reopen if it there are still/more issues. BTW, I still think another content type description, with own detector, and, perhaps, higher priority, coming from m2t.xpand project, is better solution. Did anyone try that? [target cleanup] 2.2 M7 was the original target milestone for this bug [GMF Restructure] Bug 319140 : product GMF and component DevTools was the original product and component for this bug |
The plugin.xml in bundle "org.eclipse.gmf.xpand" contains a declaration for a content-type, which sets the the default encoding of all files ending with *.xpt to ISO-8859-1: <extension point="org.eclipse.core.runtime.contentTypes"> <content-type base-type="org.eclipse.core.runtime.text" default-charset="ISO-8859-1" file-extensions="xpt" id="org.eclipse.gmf.xpt" name="%contenttype.xpt" priority="normal"> </content-type> </extension> This makes working with a different encoding nearly impossible (I have to set the encoding explicitly on every resource) and therefore breaks existing projects. This is not only a problem for existing GMF projects, but also for all M2T/Xpand (and oAW) projects, as all these projects use the same file extension. If you really think it is a good idea to presume ISO-8859-1 for all files, please make sure that it is only applied for GMF Xpand.