entical to "Mär". Setting the
Locale to the US in setup doesn't help. Until there is a better solution, I'm
taking Tim's suggestion to adust the expected results. See also thread on dev:
https://mail-archives.apache.org/mod_mbox/tika-dev/201910.mbox/%3Cd55a
[
https://issues.apache.org/jira/browse/TIKA-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilman Hausherr resolved TIKA-2959.
---
Resolution: Fixed
> TabularFormatsTest test fails in Germ
java
> TabularFormatsTest test fails in Germany
>
>
> Key: TIKA-2959
> URL: https://issues.apache.org/jira/browse/TIKA-2959
> Project: Tika
> Issue Type: Bug
> Com
java
> TabularFormatsTest test fails in Germany
>
>
> Key: TIKA-2959
> URL: https://issues.apache.org/jira/browse/TIKA-2959
> Project: Tika
> Issue Type: Bug
> Components:
st test fails in Germany
>
>
> Key: TIKA-2959
> URL: https://issues.apache.org/jira/browse/TIKA-2959
> Project: Tika
> Issue Type: Bug
> Components: parser
>Affects Versi
+1
Thank you!
On Sat, Oct 5, 2019 at 1:15 PM Tilman Hausherr
wrote:
> Am 05.10.2019 um 17:46 schrieb Tim Allison:
> > As for the repo, I work directly w GitHub, but wip should work.
> >
> > I don’t think we’ve codified line length, but please do as you see fit.
>
> I decided to refactor the cod
Am 05.10.2019 um 17:46 schrieb Tim Allison:
As for the repo, I work directly w GitHub, but wip should work.
I don’t think we’ve codified line length, but please do as you see fit.
I decided to refactor the code and it is much better now and the code
line length question doesn't exist anymore,
Tilman Hausherr created TIKA-2959:
-
Summary: TabularFormatsTest test fails in Germany
Key: TIKA-2959
URL: https://issues.apache.org/jira/browse/TIKA-2959
Project: Tika
Issue Type: Bug
As for the repo, I work directly w GitHub, but wip should work.
I don’t think we’ve codified line length, but please do as you see fit.
I’ve started using Maven checkstyle on another project...I shudder to think
of the amount of time it would take to get our code into shape...if only I
had a few
Thank you, Tilman!
The master branch is for 2.x and branch_1x is for 1.x
On Sat, Oct 5, 2019 at 10:30 AM Tilman Hausherr
wrote:
> Am 04.10.2019 um 17:32 schrieb Tim Allison:
> > Would it work to set the expected String to something generated with the
> > root locale?
>
> I managed to create suc
Am 04.10.2019 um 17:32 schrieb Tim Allison:
Would it work to set the expected String to something generated with the
root locale?
I managed to create such code: we need both the US and the local month
names. I get these with
new DateFormatSymbols(Locale.getDefault()).getShortMonths()
Be
Y. It could be a configuration problem. I agree that something weird
is going on in that you're getting a failure with the full build but
everything works ok with the local setting of Locale.
I think the full solution would allow users to pass in Locale via
ParseContext...and that _might_ work w
Am 04.10.2019 um 17:32 schrieb Tim Allison:
Would it work to set the expected String to something generated with the
root locale?
Yes, that makes sense.
But I'm wondering whether this is a configuration problem - am I the
first one outside the US who tried doing a build from source?
Tilman
Would it work to set the expected String to something generated with the
root locale?
On Fri, Oct 4, 2019 at 10:56 AM Tilman Hausherr
wrote:
> So I wanted to build tika from source, and failed:
>
> Failures:
>TabularFormatsTest.testSAS7BDAT:229->assertContents:216 en_US Wrong
> text in row 9
So I wanted to build tika from source, and failed:
Failures:
TabularFormatsTest.testSAS7BDAT:229->assertContents:216 en_US Wrong
text in row 9 and column 7 - 03(MAR|Mar)(63|1963)[:\s]09:46:40(.00)? vs
03Mär1963:09:46:40.00
TabularFormatsTest.testXLS:236->assertContents:216 en_US Wrong text
15 matches
Mail list logo
