Hi All,
I think that some actions may be taken from OCL point of view:
1. The number of files which have the spanish acuted vowel are limited.
Actually, some contributions have my surname without the acute. So, I'm
inclined to open a bugzilla so that all the "Sánchez" appearances are
changed to "Sanchez".
2. Doing 1, doesn't ensures that all works again. We could still have
the problem of having other weird characters encoded with any encoding
char set different from UTF-8. So, we could :
a) Revert the change which stablished the non-tests plugins the
UTF-8 encoding.
b) Find out any other non UTF-8 encoded character, so that they are
properly encoded.
I would do 1 (which will always avoid any kind of problem related to
file encoding and weird characters) and any of the alternatives of 2.
Regards,
Adolfo.
Ed Willink escribió:
Hi Ed
The encoding problem has been around since at least 16-Oct-2008 when
Christian committed some of Adolfo's code with the contributor comment:
* Adolfo S�nchez-Barbudo Herrera - Bug 233673
At that time all OCL plugins had unspecified encoding, so the magic
character changed depending who checked out/in on what system.
The problem has become more apparent since the agreement in Bug 291310
to impose UTF-8 on JUnit plugins so that tests of Unicoide strings
would run on both Linux and Windows. Unfortunately a UTF-8 encoding has
been applied for the non-test plugins too.
For me on Windows, with Sun compilers, setting UTF-8 on all plugins is
just an aesthetic inelegance. I see a rubbish character in a comment.
Clearly this is causing bigger problems elsewhere. Can you elaborate on
what tools are failing?
Probably we should back out the UTF-8 on the non-test plugins.
I have just run all the Ecore-binding tests on Vista with 3.6M3
platform, EMF fresh from CVS HEAD, MDT/OCL fresh from CVS HEAD, no
build problems. 1 test failure on a missing "eContents()" method. Maybe
the visible Ecore model has changed. Certainly nothing dramatic like
help why is everything broken? The UML2 plugins are still checking out
very slowly.
Ed
Ed Merks wrote:
Ed,
Comments below.
Ed Willink wrote:
Hi
Ed
Fixing the builds is my fun for this weekend.
Builds are endlessly entertaining. :-(
Something in UML2 broke 19 OCL tests three weeks ago. Bug 294848.
Maybe that was an EMF-caused problem that's been fixed now....
https://bugs.eclipse.org/bugs/show_bug.cgi?id=296194
A first glance through the recent build failure doesn't show anything
that shouts where the fault is. There are some suspicious diagnostics
concerning EMF. Maybe the models need regenerating to use the latest
EMF.
Not sure.
What tool do you use to display the file formats/find that they cause
problems?
I simply extracted the project into my workspace and it fails to build,
complaining the file isn't readable. Opening it up shows an error
about the encoding being invalid and let's you change it. When I set it
to ISO-Latin, the file them displays properly. So it seems to be
encoded as ISO-Latin, while the project level preference is for all
files to be UTF-8 encoded.
Ed
Ed Merks wrote:
Ed,
The preferences for org.eclipse.ocl sets the encoding for the project
to UTF-8, but apparently all the files in that project are not encoded
as UTF-8. TypeUtil being just one example of a file encoded as ISO
Latin and not being readable as UTF-8. Is there something you're doing
when editing and committing changes that producing the wrong encoding?
The changes in OCL seem to have left the modeling technology stack in
shambles (QVT, GMF, Query, and Validation are all broken it seems) and
that has me very concerned. What are all the downstream projects doing
to address the impact of these changes? How will it be possible to
create milestone builds for the whole stack in the coming weeks?
The cross project communication to date has been exceedingly poor.
Regards,
Ed
Ed Willink wrote:
Hi Ed
This has been discussed in Bug 291310. The offending characters should
only be in JUnit tests.
(Ah. I just committed a contribution from Patrick Könemann <mailto:pk@xxxxxxxxxx>. In the
past Adolfo Sanchez has had an
accent on his a.
These are all in comments, where .).
The code usage was where Christian tested that a quoted string could be
quoted with other variants of single quote such as Hebrew. Since this
was never in the OCL spec, and one of my recent OMG resolutions
(currently voted 1 for, 3 abstaining) makes such quotes illegal, it is
not clear that we needed UTF-8 in code at all, except that more
recently we've been needing to test Unicode identifiers.
We therefore set the plugin preferences to UTF-8 which ensured that
both our Windows and Linux users were able to get 100% JUnit passes. I
think Alex is still working on the build aspects. We also have a JUnit
test that checks that UTF-8 is in force.
I hope this allays your concerns.
Regards
Ed
Ed Merks wrote:
Ed,
It doesn't seem like a good idea to check in files with ISO-Latin
characters as you've recently done with a number of OCL files.
Sticking to ASCII seems better because then they can be opened as
ASCII, ISO-Latin, or UTF-8. If you must use some other encoding, it's
probably important that the encoding you're using is captured in CVS
itself sot hat it is applied when the files are checked out by others.
Regards,
Ed
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.709 / Virus Database:
270.14.93/2544 - Release Date: 12/04/09 07:32:00
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
--
|
Adolfo
Sánchez-Barbudo Herrera
adolfosbh(at)opencanarias(dot)com
C/Elías Ramos González, 4, ofc. 304
38001 SANTA CRUZ DE TENERIFE
Tel.: +34 922 240231 / +34 617 718268 |
|
