Hibernate Testing 6 & JUnit 5.14

Hibernate ORM
1

Hi

I’m using Hibernate Testing 6.6.45 and JUnit 5.14 and I get this error:

org.junit.platform.commons.JUnitException: TestEngine with ID 'bytecode-enhanced-engine' failed to execute tests

Caused by: java.lang.NoSuchMethodError: 'void org.junit.jupiter.engine.execution.JupiterEngineExecutionContext.<init>(org.junit.platform.engine.EngineExecutionListener, org.junit.jupiter.engine.config.JupiterConfiguration)'
	at org.hibernate.testing.bytecode.enhancement.extension.engine.BytecodeEnhancedTestEngine.createExecutionContext(BytecodeEnhancedTestEngine.java:231)
	at org.hibernate.testing.bytecode.enhancement.extension.engine.BytecodeEnhancedTestEngine.createExecutionContext(BytecodeEnhancedTestEngine.java:48)

I saw that class LauncherStoreFacade has been moved to the package org.junit.jupiter.engine.execution. Isn’t there a plan to update it to at least version 5.14?

Thanks

2

We don’t have any plans to do that, no. We updated to JUnit 6 in ORM 7.2 via HHH-19832 and made sure that the new version also still supports 5.13 via https://github.com/hibernate/hibernate-orm/commit/14cdc617535f0470975d14c511a8a474ae7380c3, but we are not going to backport such improvements. Also see the big yellow warning sign and our maintenance policy for details about the process.

3

It is not possible for us to use that combination, we will use JBoss 8.1 and Spring Boot 3.5, we certainly cannot switch to an unusable version, and, leaving aside the acceleration in the release of new versions that are not adequately supported, at this point we should throw away all the tests done up to now with your library.

4

Why do you think ORM 7.1+ is unusable? Spring Boot 4.0 also updated to that.

You don’t have to throw away all the tests you have done so far, but understand that we have a maintenance policy. If you want “stability”, this means you can’t upgrade dependency versions other than bug fix versions. hibernate-testing 6.6 was written to work with JUnit Jupiter 5.13, so you can’t just upgrade JUnit in your app if you use this artifact. It’s as simple as that.

You can also just create your own version of hibernate-testing that works with newer JUnit versions, but we have decided and published that our maintenance policy demands stability, which means no backports of features or enhancements. If you are a Red Hat or IBM customer, you might be able to convince us that we should support newer JUnit versions also in such limited-maintenance branches.

5

The point is that for contractual reasons, we must adhere to the specifications and what is supported by JBoss EAP 8.1 (JEE 10). We can’t use SB 4 until JBoss also supports JEE 11.

The 6.6 artifact was developed for JUnit 5.13, this doesn’t mean it couldn’t also work with 5.14, which I believe will be the last of the 5.x versions. But that’s not the point, the point is that your implementation is based on a construct that effectively constrains and blocks your libraries.

You can also just create your own version of hibernate-testing that works with newer JUnit versions, but we have decided and published that our maintenance policy demands stability, which means no backports of features or enhancements. If you are a Red Hat or IBM customer, you might be able to convince us that we should support newer JUnit versions also in such limited-maintenance branches.

This isn’t viable and isn’t acceptable, much like your policies, so I’m afraid the only option left is to abandon your testing library. We’ll definitely keep these restrictions in mind when using your library in the future.

Thanks.