Hi,
And what about use the Java numberFormatting in test in order to be
"locale independant" ?
---
Extract from java API [1] :
To format a number for the current Locale, use one of the factory class
methods:
myString = NumberFormat.getInstance().format(myNumber);
---
Maybe something like this in the test code will solve the problem :
assertTrue(content.contains(NumberFormat.getInstance().format("1,599.99")));
Regards
[1] : http://java.sun.com/j2se/1.4.2/docs/api/java/text/NumberFormat.html
On Thu, 11 Mar 2010 13:07:13 +0100, Ruben Laguna <ruben.lag...@gmail.com>
wrote:
> Thanks for the info. I actually solved by running
>
> export LC_ALL=en_US.UTF-8
> mvn install
>
> that sets the locale temporarily to en_US in my system (mac os x snow
> leopard). And I was able to build the jar this way. I described the
process
> in more detail in [1]
>
> [1]
>
http://rubenlaguna.com/wp/2010/03/10/building-apache-tika-0-6-fails-if-the-locale-is-not-en_us/
>
> On Thu, Mar 11, 2010 at 11:22 AM, Daan de Wit <d.de....@o3spaces.com>
> wrote:
>
>> Hi Rubén,
>>
>> Jukka actually filed a bug-report for this issue against POI:
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=48617, I don't know
if
>> Tika already depends on this version of POI, so it might be best to
just
>> disable the failing tests.
>>
>> Kind regards,
>> Daan
>>
>> On 9 March 2010 22:12, Ruben Laguna <ruben.lag...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I tried to build tika 0.6 with mvn install and two testcases fails
>>> (which
>>> prevents the build from completing)
>>>
>>>
>>>
testExcelParserFormatting(org.apache.tika.parser.microsoft.ExcelParserTest)
>>>
testExcelFormats(org.apache.tika.parser.microsoft.ooxml.OOXMLParserTest)
>>>
>>> I took a look to testExcelParserFormatting and it fails on the first
>>> assert
>>> assertTrue(content.contains("1,599.99"));
>>>
>>> because contens contains "1.599,99" and not "1,599.99" I suspect that
>>> this
>>> is due to the fact that in my locale (swedish) the number formatting
is
>>> different.
>>>
>>> Is there anyway to fix this? Actually I not really interested in
Excel
>>> at
>>> all, so I wouldn't mind to disable the excel parser altogether. is
this
>>> possible?
>>>
>>> --
>>> /Rubén
>>>
>>
>>
