I just found the blog post above and I am not happy. The least they could have done is make it configurable.
I understand the frustration. We're all feeling it. The article you found describes it: "A tidal wave is rippling through the Java ecosystem. It is the renaming of javax to jakarta package names."
The clock's ticking. Starting from Spring Boot 3.0, you'll have to upgrade anyway, possibly even before:
https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6
Other frameworks will also soon upgrade, too. The rename is painful for everyone, yes, but there's not too much value in maintaining two dependencies forever, especially not if the library uses the features as little as jOOQ.
The alternatives are documented in the blog post you had referenced from a previous edit. There was almost no feedback from the community with respect to what would be a better alternative (there have been complaints, of course, but I'm not sure if anything better could have been done). In your particular case, you could simply regex-replace all generated output to patch the imports again. That's what jOOQ itself is doing with the generated JAXB annotations, because even the XJC plugins that generate the code aren't all ready for this messy rename.
Yes, there could have been a configuration option, but then again, what about the runtime dependencies on JAXB and JPA? Those can't be duplicated or configured easily. Would it have been worth it to have both on the classpath? Or to ship two separate distributions? Not too likely. It's a different case compared to e.g. Hibernate, which depends heavily on the specifications, but jOOQ doesn't, really.
I guess I will be using an old version.
You can, of course. But then again, is that really worth it? What are you using the feature for? Could you just drop generating those annotations?