Hide journal recovery messages during test suite run

[adamretter]

Stops the CI logs from getting polluted

[dizzzz]

It looks like the PR contains content of another PR?

[reinhapa]

Great enhancement to have less output during tests!

[adamretter]

@dizzzz @reinhapa I kept the journal improvements and CI improvements in a single PR, as that is what I had already done for 4.x.x, 5.x.x, and 6.x.x; albeit in those cases I needed to do both in a single PR to be able to see what was going on. I kept these things as separate commits at least. If you feel this PR here must be split into two - let me know and I will do so...

[dizzzz]

It is OK for me, as it is intentional

[duncdrum]

I m also curious what the JDK has to do with it. Since we use temurin not just on CI here, but also in Docker and all other repos in the org, I m not a fan of changing it without reason. If there is a reason to change, we should stay consistent elsewhere in the org.

[reinhapa]

I'm ok changing the JDK for the sake of having the old versions, but on the develop branch I would prefer to leave it using the temurin one...

[dizzzz]

It looks like that switching to the JVM Adam suggested all kind of strange test/fork/... issues occur.

Looking at the discussions it is probably better to split the jvm change and the recovery log code delta.

[reinhapa]

It looks like that switching to the JVM Adam suggested all kind of strange test/fork/... issues occur.

Looking at the discussions it is probably better to split the jvm change and the recovery log code delta.

We then at least can rule out side effects from the JDK change... Just to be clear I'm full in the hiding suff!

[line-o]

I do appreciate hiding the journal progress bar in CI!
I would like to see as @dizzz and @reinhapa that only the changes necessary for that to work would be included in this PR.
I would also like to see them in just one or two commits.

[adamretter]

I m also curious what the JDK has to do with it.

@duncdrum (cc @reinhapa) As I wrote before you posted, see: "as that is what I had already done for 4.x.x, 5.x.x, and 6.x.x"

Since we use temurin not just on CI here, but also in Docker and all other repos in the org, I m not a fan of changing it without reason.

@duncdrum We are now using Liberica (and not Temurin) for eXist-db 4.x.x, 5.x.x, and 6.x.x. I am also a fan of consistency and so I wanted to use Liberica also for 7.x.x in THIS repo.
Regards Docker, I think you may be mistaken, we are not using Temurin and we never have:

1. For eXist-db 7.x.x in Docker we are using OpenJDK (from gcr.io/distroless/java17:latest base image), see: https://github.com/GoogleContainerTools/distroless/blob/main/java/README.md
2. For eXist-db 6.x.x in Docker we are using OpenJDK, see: https://github.com/eXist-db/exist/blob/develop-6.x.x/exist-docker/src/main/resources-filtered/Dockerfile#L28
3. For eXist-db 5.x.x in Docker we are using OpenJDK, see: https://github.com/eXist-db/exist/blob/develop-5.x.x/exist-docker/src/main/resources-filtered/Dockerfile#L28
4. For eXist-db 4.x.x in Docker we are using OpenJDK, see: https://github.com/eXist-db/docker-existdb/blob/master/Dockerfile#L28

If there is a reason to change

Yes, the features of eXist-db 4.x.x, 5.x.x, and 6.x.x only reliably run 100% on Java 8. Whilst you can run some parts of eXist-db 4.x.x, 5.x.x, and 6.x.x on newer Java, you will find various parts that throw exceptions due to changes in the JDK after Java 8; JAXB, Mail, Activation, Image, etc.

There does not appear to be a Temurin build available for Java 8 in macOS (at least in CI) so we simply can't use Temurin in CI, however there is one for Liberica. That is the reason for the change.

I see a reason to drop Temurin, but no reason not to use Liberica (which is also based on OpenJDK).

we should stay consistent elsewhere in the org.

I am not so concerned about other repos in this org as they each have different requirements that I expect to be set by the owners of those repos.

As the JDK change seems to be of concern, I will move it to a separate PR. However I think that we should choose one JDK vendor across 4.x.x, 5.x.x, 6.x.x, and 7.x.x and stick to it in this repo. As Temurin won't work for us (no JDK 8 support on macOS in CI) we need to choose one of the others.

[adamretter]

@dizzzz @reinhapa I have moved JDK change out of this PR and into a new PR - #5480

[sonarcloud]

Quality Gate failed

Failed conditions
68.6% Coverage on New Code (required ≥ 80%)
B Reliability Rating on New Code (required ≥ A)

See analysis details on SonarCloud

Catch issues before they fail your Quality Gate with our IDE extension SonarLint