kotlin-jdsl
kotlin-jdsl copied to clipboard
line
Check my temporary JPA 3.0 (Jakarta) fork for Hibernate 6
JPA 3.0 (Jakarta), Hibernate 6 fork
I created a fork so you can use this great network with JPA 3.0 that usually comes with Hibernate 6: https://github.com/Tankonyako/kotlin-jdsl-jakarta ⚠️ This can't work with Spring and Reactive as they don't support Jakarta and the latest versions of Hibernate.
I saw the mail too late, so I am leaving an answer now. Thank you for suggestion first.
When I checked the repo, support for the jakarat package is as the main content. However, this way seems to have a problem that it is difficult to maintain compatibility with existing libraries. We intend to isolate the module of the kotlin-jdsl internal code as a way to support jakarta.
The DSL and Spec objects are built with pure kotlin code that has nothing to do with the external library, and through the Spec objects, each engine, such as Eclipse, JPA 2.0, and 3.0, parses it and executes query with Spec on its own. So, there are three modules, such as DSL, Spec, Engine. In this way, the user only change dependency of engine module to use jakarta.
But for this, the whole code and structures of JDSL should be changed. We are currently preparing work for this, but I think we will be able to show this module structure next year due to other work.
Thank you again for your suggestion.
hello. Have you been working on it lately? If you are doing it, it would be nice to do collabo together. If not, I will try to upgrade the jakarta package version. Please answer
hello. Have you been working on it lately? If you are doing it, it would be nice to do collabo together. If not, I will try to upgrade the jakarta package version. Please answer
i think i can help you, but what you want? You need only use my package, but my package doesn't have some features, and works with jakarta not javax
⚠️ This can't work with Spring and Reactive as they don't support Jakarta and the latest versions of Hibernate.
Since the release of Spring Boot 3 and Spring Framework 6.0, kotlin-jdsl is no longer working because everything has switched to the jakarta namespace. So regarding the original comment: now it's supported :)
I was busy with work so the reply was very late. sorry.
Currently, jdsl is facing a big change next year. Currently, queries are created using JPA Criteria, and future changes are highly likely to be query builders that directly create queries through dsl. Therefore, it has the potential to be a general query builder rather than a technology specific to one JPA technology. Of course, when creating a JPA query, I would like to create JPQL directly and otherwise create a native query.
Apart from that, the current situation is that many libraries are moving from JPA 2.2 to jakarta EE 3.0. But we can't help but think of many people who don't use 3.0. And the current standard hibernate reactive does not support the jakarta EE version. However, it seems to be preparing for a separate release because it has a jarkata branch.
First of all, I want to choose one of the directions listed below. Many comments are appreciated.
- Create modules for jakarta. ex: core-jakarta, hibernate-jakarta
- This method causes a lot of code duplication. However, it is not bad as a temporary response before a big change next year.
- As long as hibernate-reactive does not support jakarta EE, hibernate-reactive-side modules designate the dependency of the upper module as 2.0.7 (or 2.0.x), and all other modules convert to jakarta.
- In this case, we have to take the strategy of the rest of the jdsl versions like 2.1.x, and hibernate-reactive related modules cannot support changes in upper modules for the time being.
- Or, in method 2, create a 2.0.x branch and follow hibernate-reactive or other changes based on JPA 2.2 standard, and main maintains jakarta EE.
Please comment on which method is better.
@shouwn @Tankonyako @LevinGermann @pickmoment @huisam
Based on what cj848 said, it is difficult in multiple modules to release new versions at the same time due to hibernate-reactive. I don't want to choose a strategy to separate branches because it increases deployment complexity. Therefore, I think it is better to support the new library by making core-jakarta.
If there is no special opinion, I will proceed according to @shown's opinion above. If that's the case, @Tankonyako's branch work posted in this thread is expected to be difficult to use. After creating a separate module, I will create a spring jakarta module suitable for the jakarta module.