HibernateOrmRestDataPanacheTest is generating a false negative in a non english locale

[patrox]

Describe the bug

I'm using macOS with a polish language/locale set - when I tried to build Quarkus (including tests), it failed at HibernateOrmRestDataPanacheTest, with the following output:

[ERROR] Failures:
[ERROR]   HibernateOrmRestDataPanacheTest.shouldNotCreateBookWithBlankTitle:183 1 expectation failed.
JSON path parameterViolations[0].message doesn't match.
Expected: must not be blank
  Actual: nie może być odstępem

FYI: the "nie może być odstępem" means exactly "must not be blank".

Expected behavior

Tests are passing regardless of which locale is set.

Actual behavior

Tests are passing in the case when the English locale is set.

To Reproduce

Steps to reproduce the behavior:

1. Switch your OS language/locale to a non-EN one (might require a restart)
2. Run HibernateOrmRestDataPanacheTest (it should fail)

Environment (please complete the following information):

LANG=pl_PL.UTF-8

Output of java -version

openjdk version "13.0.2" 2020-01-14
OpenJDK Runtime Environment (build 13.0.2+8)
OpenJDK 64-Bit Server VM (build 13.0.2+8, mixed mode, sharing)

GraalVM version (if different from Java)

Quarkus version or git rev

787bc2c

I will be happy to take care of this issue, as i.e. it could be fixed by either:

1.) Setting a default locale in application.properties, as described here: https://quarkus.io/guides/validation#validation-and-localization

2.) Or forcing tests to use a default locale, by configuring it via maven-surefire-plugin: https://stackoverflow.com/questions/8901880/set-surefire-plugin-locale-in-maven-pom-file

[quarkus-bot]

/cc @FroMage, @Sanne, @gsmet, @loicmathieu, @yrodiere

[famod]

Can you (also) try adding:

-Duser.language=en
-Duser.country=US

to .mvn/jvm.config? (without trainling newline!)

[patrox]

Hey @famod, your suggestion seemed like a perfect solution, as it would set the default locale settings for a particular project, without messing up the system-wide locale.

Unfortunately, when I tried to set them via the existing jvm.config file, it didn't help. I went a step further and tried to explicitly pass them to a mvn command that was used to run the tests, but it didn't help either.

Then, I've found out that this is most probably caused by the fact that tests are run by mvn in a forked process, which might cause that the locale is lost, and it defaults to the system one.

https://stackoverflow.com/questions/8901880/set-surefire-plugin-locale-in-maven-pom-file

https://www.mail-archive.com/[email protected]/msg98949.html

This might be solved by configuring the maven-surefire-plugin to use this explicit locale, i.e.:

<plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <configuration>
            <argLine>-Duser.language=en -Duser.region=GB</argLine>
        </configuration>
   </plugin>

So, WDYT @famod, @Sanne ?

[gsmet]

We need to include it in the Surefire config in the pom.xml. We shouldn't require any sort of local adjustments.

[patrox]

We need to include it in the Surefire config in the pom.xml. We shouldn't require any sort of local adjustments.

I can try to tackle it, as I'll need it for sth else - as I would like to work on an extension, so I'll be happy to take care of it.

[gsmet]

I already have a patch for it, sorry :)

[patrox]

@gsmet np, as long as it's done, I'll be happy.

[gsmet]

Here it is: #18048 . Pushing variables for surefire was enough in JVM mode but it's a bit more complicated with native. I ended up configuring Quarkus itself.

[famod]

@patrox

Then, I've found out that this is most probably caused by the fact that tests are run by mvn in a forked process, which might cause that the locale is lost, and it defaults to the system one.

Ah, sure! I forgot that I disabled the propagation of MAVEN_OPTS to surefire not long ago (mvnw appends everything from jvm.config to MAVEN_OPTS).

@gsmet
FWIW, there is a LANG env var in the workflow: https://github.com/quarkusio/quarkus/blob/main/.github/workflows/ci-actions-incremental.yml#L42
So there is a kind of consistency issue (CI vs local, possibly), but for a long time already.