Update dependabot config and update dependencies where possible

[marko-bekhta]

Hey @gsmet 😃

after opening #1344 because of the issues building the project when using the JDK 21 and doing the SM removal work in #1345 I thought that maybe we should enable dependabot and keep the build of the Validator more up to date so it'll be more straightforward to address any build issues rather than waiting for them to pileup...

I've used the similar dependabot config that we have in the Search.
The only thing I couldn't upgrade is Wildfly because of jbossas/patch-gen#34 😔 but it looks like that project is a bit stale 😔😔😔

[hibernate-github-bot]

Thanks for your pull request!

This pull request does not follow the contribution rules. Could you have a look?

❌ All commit messages should start with a JIRA issue key matching pattern HV-\d+
    ↳ Offending commits: [98021a2, 67eb2fd, b7fd4ba, b276886, 8fd626b, b3f3f2c, 3fb8a3f, 81f24a4, 1f9463b, c2722e6, 0d182b6, f8030e8, 342cf6a, 19b308f, edb0328, 2f4916b, 09cc300, b89ed41, 8067ed2, 942c1d0, b87504c, 0bb359e, aee1e0f, 9d82106]
❌ The PR title or body should list the keys of all JIRA issues mentioned in the commits
    ↳ Issue keys mentioned in commits but missing from the PR title or body: [HV-1974]

› This message was automatically generated.

[gsmet]

I would say +1 but CI looks unhappy?

[yrodiere]

DEBUG: figure out why TCK test failing on CI only

Aw shoot, I'm missing all the fun 😁

[marko-bekhta]

DEBUG: figure out why TCK test failing on CI only

Aw shoot, I'm missing all the fun 😁

🙈 😄 mmmmmmmm ooooook... so the problem is caused by:

file:/var/lib/jenkins/workspace/hibernate-validator_PR-1347%40tmp/maven-repository/org/assertj/assertj-core/3.8.0/assertj-core-3.8.0.jar
file.exists() = false
file.isFile() = false
file.listFiles() = null

Which, if we don't upgrade the surefire plugin, is:

file:/var/lib/jenkins/workspace/hibernate-validator_PR-1347@tmp/maven-repository/org/assertj/assertj-core/3.8.0/assertj-core-3.8.0.jar
file.exists() = true
file.isFile() = true
file.listFiles() = null

For some reason with the plugin upgrade @ gets encoded in the path, and I'm not sure how that's connected since the URL comes from:

Assert.class.getProtectionDomain().getCodeSource().getLocation()

which isn't surefire related 🤔😕

and that's happening inside of the TCK classes .... it's fixable, but I guess we aren't getting a new version of TCK to make this work 🤔

[yrodiere]

For some reason with the plugin upgrade @ gets encoded in the path

I remember similar problems from when we worked on running Jandex indexing on startup in Hibernate Search... I don't remember what I changed to fix it, but here's the test that checked it worked, and I suppose the fix is somewhere in the same commit: hibernate/hibernate-search@2773f90#diff-fa81f1bd295eb29f597f67849a355691e3672277da2aa60d41156433b3935971R257-R258

Does that help in any way?

[marko-bekhta]

Thanks 😃
I've opened jakartaee/validation-tck#198, since the access to the code source happens inside the TCK classes, calling .toURI() helps, at least in the tests I've run locally. But since it's all TCK code, I guess it's one of:

• we get a new TCK
• we don't upgrade the surefire plugin (that, for some reason, causes the issue)
• we do something to Jenkins jobs that they do not include any chars that get encoded in the file paths

[yrodiere]

I've opened jakartaee/validation-tck#198, since the access to the code source happens inside the TCK classes, calling .toURI() helps

Thanks. @gsmet could you add your +1 to that PR, since I guess your opinion has great weight over there? I imagine Scott is quite busy right now, so your advice could help expedite things.

we get a new TCK

Probably a good idea if we merge this in HV 9.0 with Jakarta 11 support.

we do something to Jenkins jobs that they do not include any chars that get encoded in the file paths

That's going to be challenging, as the part of the path that causes the problem is somewhat standard (it's a temp dir that's available to each job) and not configurable AFAICS.

we don't upgrade the surefire plugin (that, for some reason, causes the issue)

Or... we upgrade, but find some config option that reverts to the old behavior. Not sure if this is possible though.