Bug 393353 - Test failure in EncodingChangeTests on the Hudson Mac
Summary: Test failure in EncodingChangeTests on the Hudson Mac
Status: VERIFIED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Text (show other bugs)
Version: 4.3   Edit
Hardware: PC Mac OS X
: P3 normal (vote)
Target Milestone: 3.8.2   Edit
Assignee: Markus Keller CLA
QA Contact:
URL:
Whiteboard:
Keywords: test
Depends on:
Blocks:
 
Reported: 2012-11-01 12:45 EDT by Markus Keller CLA
Modified: 2012-11-21 08:12 EST (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Keller CLA 2012-11-01 12:45:28 EDT
junit.framework.ComparisonFailure: expected:<US-ASCII> but was:<null>
at org.eclipse.ui.editors.tests.EncodingChangeTests.testChangeEncodingViaEncodingSupport(EncodingChangeTests.java:147)
at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:650)
...

This test has been failing for a few weeks on the Hudson Mac, but we could never reproduce locally. Now I finally found the cause:

The test runs with file.encoding set to "US-ASCII". I doubt that this is the default encoding on any Mac. On mine with en_US locale, the default is MacRoman (with 1.6 and 1.7 VMs).

David, do you set the encoding explicitly anywhere?

Nevertheless, we need to make the test more robust (e.g. by choosing a different encoding if the default is already US-ASCII).
Comment 1 David Williams CLA 2012-11-01 14:20:59 EDT
No, I don't set it explicitly anywhere, but by probing this specific machine, I see that 

+ locale charmap

returns 

US-ASCII

This does seem unusual to be the OS default (my mac machine, not installed or set up by me, returns UTF-8, which I think is the usual default)  ... but ... guess its "good" that this machine provides an interesting test case!  

CCing webmasters to ask: 

Matt, when you set up this machine, did you choose "US-ASCII" on purpose? For a reason? I'm not saying you should change it now, just asking, now. Eventually, though, there might be other issues with this setting ... but, if this test is the only issue then its fine the way it is. 

FWIW, Eclipse committers, I _could_ likely set/export a specific value to override the OS default, just for our tests, but ... it would be best to make tests robust to handle any OS default setting.
Comment 2 Eclipse Webmaster CLA 2012-11-01 14:45:31 EDT
I don't recall seeing an encoding selection box while setting up the new Mac, but it may have interpreted my locale selections(this isn't the encoding you're looking for).

As for the 'original' Mac, I didn't set it up(from scratch) so I can't speak to that.

-M.
Comment 3 Markus Keller CLA 2012-11-08 05:37:43 EST
> Nevertheless, we need to make the test more robust (e.g. by choosing a
> different encoding if the default is already US-ASCII).

Fixed with http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=39f38f8a19e97dd51aa23354fc44752a5903ce06
Comment 4 Dani Megert CLA 2012-11-08 06:13:30 EST
(In reply to comment #3)
> > Nevertheless, we need to make the test more robust (e.g. by choosing a
> > different encoding if the default is already US-ASCII).
> 
> Fixed with
> http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/
> ?id=39f38f8a19e97dd51aa23354fc44752a5903ce06

http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=39f38f8a19e97dd51aa23354fc44752a5903ce06

that is.
Comment 5 Dani Megert CLA 2012-11-12 04:26:29 EST
Cherry-picked the fix into 'R3_8_maintenance' with http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=157d86b3c2b072256343af0016e9d363e1fd522a
Comment 6 Dani Megert CLA 2012-11-21 08:12:53 EST
Verified in M20121114-1000 and M20121114-1200.