Bug 579824 - Unparser tests not executed on build server
Summary: Unparser tests not executed on build server
Status: NEW
Alias: None
Product: QVTo
Classification: Modeling
Component: Engine (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows 10
: P3 trivial (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-05-03 08:55 EDT by Christopher Gerking CLA
Modified: 2022-08-25 07:53 EDT (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Gerking CLA 2022-05-03 08:55:29 EDT 
The unparser tests developed for bug 377320 are currently not executed during the Tycho builds. Add them to the AllTests suite.
Comment 1 Eclipse Genie CLA 2022-05-17 05:57:41 EDT 
New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/193409
Comment 2 Christopher Gerking CLA 2022-05-19 08:42:13 EDT 
The Gerrit build succeeded, but now I'm suddenly facing failures on the local Maven build:

runTest[TestData localstrings --> 0/0/0 (org.eclipse.m2m.tests.qvt.oml.TestQvtUnparser)  
Time elapsed: 0.084 s  <<< FAILURE!
junit.framework.AssertionFailedError: 

Original and copy expression differ at 1 places
RangeDifference {CHANGE/RIGHT, Left: (39, 1) Right: (39, 1)}
----LEFT:                    stringSymbol="ТекÑ?Ñ‚"/>
----RIGHT:                   stringSymbol="?????"/>
	at org.eclipse.m2m.tests.qvt.oml.TestQvtUnparser.assertEclipseCompareEquals(TestQvtUnparser.java:552) 
at
org.eclipse.m2m.tests.qvt.oml.TestQvtUnparser.runTest(TestQvtUnparser.java:530)

The failure could be due to the encoding of the 'Текст' string in localstrings.qvto, but sometimes it also happens with the "_while_261024" case instead of "localstrings" (apparently never with both in the same run).
Comment 3 Ed Willink CLA 2022-05-19 15:01:15 EDT 
Make sure that every (relevant) project is explicitly UNIX+UTF8.

If you have set the workspace to UNIX+UTF8 you might find some project deviates at run-time.

Edit and save every relevant test file to verify that standard editors display correctly.
Comment 4 Eclipse Genie CLA 2022-05-20 09:03:38 EDT 
New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/193545
Comment 5 Eclipse Genie CLA 2022-05-20 09:03:39 EDT 
New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/193546
Comment 6 Christopher Gerking CLA 2022-05-20 09:19:53 EDT 
(In reply to Ed Willink from comment #3)
> Make sure that every (relevant) project is explicitly UNIX+UTF8.
Thanks, but the problem seems to be that the Maven surefire plugin must be configured explicitly for UTF8: https://stackoverflow.com/questions/17656475/maven-source-encoding-in-utf-8-not-working

Interestingly it doesn't seem to make a difference for the Gerrit build, which succeeds with or without the UFT8 config. But it's needed for my local mvn build using the nightly profile.
Comment 7 Ed Willink CLA 2022-06-01 04:11:54 EDT 
(In reply to Christopher Gerking from comment #6)
> Interestingly it doesn't seem to make a difference for the Gerrit build,
> which succeeds with or without the UFT8 config. But it's needed for my local
> mvn build using the nightly profile.

The Gerrit build is on a Linux machine so it has sensible system defaults that Eclipse does not adjust at the system level.

Locally you're presumably on Windows which is crazy at the system level and for which Eclipse's system / workspace level adjustments are also crazy. Whoever wanted Cp1252 as a default? It just seems to be retained as a legacy whose only purpose is to bite us periodically.
Comment 8 Eclipse Genie CLA 2022-08-25 07:53:06 EDT 
New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/195348
Comment 9 Eclipse Genie CLA 2022-08-25 07:53:08 EDT 
New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/195349