Closed xenoterracide closed 6 years ago
I think it makes sense to manage a JPA API dependency. Arguably, we should be doing so already as our auto-configuration for JPA uses both EntityManager
and EntityManagerFactory
. We just need to decide which one and figure out how best to keep it and the Hibernate version in sync.
I have no personal preference on which one, a while ago we switched to the eclipse one because that was the "new way forward" being the reference implementation. However, it's just as easy to use the hibernate one, so long as we can expose it by itself. As far as keeping it in sync... maybe there's a way to script asking hibernate for its version and then just updating it. I've had the thought of using gradle to generate a BOM (heck, I wrote something that did that)
Given that Boot's default JPA provider is Hibernate and that there's no official JPA API dependency for JPA 2.1, I think it makes sense to manage Hibernate's API jar despite its idiosyncratic version if we want to do this now. The alternative is to wait until we're using Hibernate 5.3 and, therefore, JPA 2.2 by default. At that point we can use the official javax.persistence:javax.persistent-api:2.2
artifact.
I'm fine with this solution, and changing to javax.persistence
when that change happens for hibernate
yes, this is pulled in by hibernate, but if you're writing a module (think jigsaw) that needs to expose a JPA api as part of its public api. You may wish to do this to create things like specifications that depend on the criteria api, or entities, and have them isolated without full hibernate access.
here's the deps of the dependent module
the dep that pulls it in