[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [mdt-papyrus.dev] File Encodings (esp. for Xtend)
|
Hello, You can setup it directly for the maven/tycho part in the pom.xml <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> </properties> Francois De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de LETAVERNIER Camille Envoyé : mercredi 8 avril 2015 10:46 À : Papyrus Project list Objet : [PROVENANCE INTERNET] Re: [mdt-papyrus.dev] File Encodings (esp. for Xtend) Hi Christian, We should definitely enforce the following: - UTF-8 encoding for all files (Unfortunately, the default in Eclipse/Windows is Cp1252, but I don’t think we use any non-ASCII character except for XTend, so it should be straightforward to migrate) - Linux line breaks (\n) I don’t think there is any required exception to using UTF-8, but if one such exception occurs, it should be notified and discussed further I don’t know how to properly enforce this (I guess Oomph would help with that ? :) ). Camille De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Christian W. Damus Envoyé : mercredi 8 avril 2015 03:37 À : Papyrus Project list Objet : Re: [mdt-papyrus.dev] File Encodings (esp. for Xtend) Hi, It occurs to me that, of course, as long as our builds are running on a Linux platform and they do the Xtend compilation step (with generated Java files not maintained in the repository) then that will go a long way towards addressing this question of file encodings. Unless I’m mistaken (which is always a strong possibility) the Eclipse workspace’s default encoding on Linux platform is UTF-8, so it would the build would stumble on Xtend sources that are Cp1252-encoded. On Tue, Apr 7, 2015 at 4:43 PM, Christian W. Damus <give.a.damus@xxxxxxxxx> wrote: In trying to get the Gerrit patch for the new Papyrus diagram tests generation framework to work, I have found that all of the Xtend sources in the test bundles are encoded with the default Windows file encoding (Cp1252). This is a problem for Xtend in particular because of its use of guillemet characters (« and ») that are not in the ASCII character set. For those of us on non-Windows platforms, Cp1252 is not the default encoding, neither in Eclipse nor in any other tool. Eclipse defaults to UTF-8 encoding for the workspace (I think, or maybe I set it thus because MacRoman would be so much worse!). Consequently, the Xtend compiler breaks on trying to read these files because decoding Cp1252-encoded guillemets as UTF-8 produces characters that definitely are not guillemets. Many of our Xtend projects now actually specify UTF-8 encoding for their contents in the resource preferences in the .settings/ folder. This is extremely helpful to non-Windows contributors. Can we make it a project policy that everybody contributing do whatever it takes to ensure that all source files that they contribute use the UTF-8 encoding on every platform, except where it is necessary for some (extremely rare) reason to use a different encoding? And our code review process should enforce the UTF-8 encoding for Xtend sources so that we aren’t always having to fix it up afterwards. In the mean-time, I am running all of the sources in this particular Gerrit patch through iconv.
|
Attachment:
smime.p7s
Description: S/MIME cryptographic signature