Ø
Is
it an official decision to enforce Linux line breaks in
Papyrus ?
No;
only a strong suggestion so far. But we should take a
decision because it’s painful for comparisons & reviews
(And the Eclipse Genie keeps saying that thousands of LoC
are being modified on Gerrit Patches, because the Line
Breaks are changed)
Camille
Hi
Camille,
Is
it an official decision to enforce Linux line breaks in
Papyrus ?
Last
time I asked this question, the discussion stop without
decision : [1]
Regards,
Benoit
[1] :
http://dev.eclipse.org/mhonarc/lists/mdt-papyrus.dev/msg02083.html
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.
