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.
