Sampo from email:
This build error seems to be triggered by the windows build machine locale. The locale of the build server is affecting the results of the CQL numberFormat() function. This to me looks like a real issue and not just test case that is incompatible with windows.
When GeoTools is running en_US: numberFormat('0.0', 1.48) produces "1.5"
When GeoTools is running fi_FI: numberFormat('0.0', 1.48) produces "1,5" (in Finland, we use commas as decimal separators)
As far as I know, CQL is not used in GeoTools to produce human-readable strings but instead to form filters, and in the test case in question, to produce strings that are to be sent to the backend WFS server.
Options to clear the situation:
1. Set up a locale for the CQL parser FilterFactory which is then passed to the objects of different CQL function classes.
2. Hard code the DecimalFormatSymbols that will be used in FilterFunction_numberFormat()
3. Leave it be and change my unit test to check for the decimal separator in the current locale and have it use a different string value to compare the CQL results to.
1. The change will require quite a bit of work. The change is necessary only if numberFormat() needs to be locale-aware.
2. Easy one-liner, but we will run into issues if people actually want locale-aware strings
3. Is a minimal change "fix". It gives us least worries that we break something for people whose geoserver (or other geotools use) requires locale aware number strings from CQL expressions. This of course leaves the underlying problem unresolved.
Can anyone shed any light on whether numberFormat() needs to be locale-aware (where the locale would be defined by the server) or not? If not, 2. should be the way to go.
Andrea from email:
I'd go for 2, leaving the door open for an eventual third parameter in the function for those that need to use a non english locale.