Hi Ed
I can reproduce the problem with ibm_sdk50 but not with ibm_sdk60, so
hopefully the train crash was of limited impact.
The five offending files are now UTF-8 in CVS.
Sorry for the problems.
Ed
Ed Merks wrote:
Ed,
It would have to be a JRE difference because the JDT has its own
compiler. Yes, deleting the project level UTF-8 default preference
helps. So it does seem these five files need to opened with ISO
encoding, saved with UTF-8 encoding, and then committed back in that
way.
Note that I see other issues caused by the addition of EObject.eInvoke,
e.g., in org.eclipse.qvt.declaration.ecore; the EObject should not be
implemented directly...
Regards,
Ed
Ed Willink wrote:
Hi Ed
Thanks. An IBM/Sun compiler difference looks to be the strongest
probability. I'll have to learn how to download an IBM JDK to
investigate.
Try deleting the
/org.eclipse.ocl/.settings/org.eclipse.core.resources.prefs in all
complaining projects. If the problem just vanishes, we'll just delete
those in CVS immediately and then investigate further.
Trying a Sun JVM would also be helpful.
Ed
Ed Merks wrote:
Ed,
Here's how it looks:
I'm using eclipse-SDK-I20091201-1100-win32.zip on XP with
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build
pwi32dev-20060919 (SR3))
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32
j9vmwi3223-20060919 (JIT enabled)
J9VM - 20060915_08260_lHdSMR
JIT - 20060908_1811_r8
GC - 20060906_AA)
JCL - 20060918
I get the same problem with a pre-M3 version of Eclipse so I don't
think it's a recent Eclipse change. I don't get the problem with the
R1_3_maintenance branch. But with HEAD there are five files with this
problem, all with a recent delta.
No, the change to Ecore won't be backed out because without that
change, hundreds of useless operation literals are produced in
EcorePackage.
Regards,
Ed
Ed Willink wrote:
Hi Ed
You'll have to provide much more detail. It's firmly a WORKSFORME.
I've loaded fresh from CVS on Eclipse 3.6M3 with default workspace
preferences on Vista Home Premium. I get no edit or build problems. I
get no UML-binding test failure. I get one Ecore-binding test failure
due to the change in EModelElement inheritance from EObject. Will this
be backed out?
What IDE are you using?
What version?
What Operating System?
What hardware?
....
Ed
Ed Merks wrote:
Ed,
Comments below.
Ed Willink wrote:
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.
I'm using the IDE though.
Clearly this is causing bigger problems elsewhere. Can you elaborate on
what tools are failing?
The JDT compiler isn't compiling the file.
Probably we should back out the UTF-8 on the non-test plugins.
Or use the latest version of IDE to try to build things an fixing any
related problems by opening as ISO changing the encoding once it's open
and saving at UTF.
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.
On thing that's changed in the Ecore model itself is the explicit use
of EObject's EClass in EModel's EClass's eSuperTypes. That's only
visible via Ecore reflection not via any generated APIs.
My problem isn't everything leading up to OCL, it's everything
downstream from OCL being broken. Query, Validation, QVT, GMF. I.e.,
the better part of the modeling stack is in shambles unless various
people start to take action and it's not clear to me whether these
clients have been informed or if they will just suddenly realize one
day that it's all broken...
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
|
