Compatibility with JPA 3.0 candidate release, Jakarta EE 9
Description
JPA 3.0 is coming as part of Jakarta EE 9
The main change is a full package rename: all "javax.persistence" packages (including public API and annotations) have been renamed to "jakarta.persistence"; this has obvious dramatic changes on backwards compatibility.
On top of package names, we're also expected to change the keys of those configuration properties which used to start with "jakarta.persistence".
An interesting aspect is that no other change whatsoever is allowed; the idea here is that while this is a breaking change, it should be straight forward to upgrade by simply running a replacement script.
To keep our own work simpler, rather than working on a one-off big patch I'll work on testing a replacement script which we could run multiple times at minimal risk; this should make it simpler to forward-port further patches from before the big rename.
100% Done
Activity
Show:
Christian Beikov December 23, 2022 at 1:05 PM
Already did that for 6
Sanne Grinovero April 16, 2020 at 10:16 PM
Thanks for the link , that’s interesting!
Andrei Ivanov April 15, 2020 at 9:55 AM
Edited
See I think they have a list of APIs that can migrate
JPA 3.0 is coming as part of Jakarta EE 9
The main change is a full package rename: all "javax.persistence" packages (including public API and annotations) have been renamed to "jakarta.persistence"; this has obvious dramatic changes on backwards compatibility.
On top of package names, we're also expected to change the keys of those configuration properties which used to start with "jakarta.persistence".
More details can be found here:
https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee9/JakartaEE9ReleasePlan
The main changing PR:
https://github.com/eclipse-ee4j/jpa-api/pull/231
The JPA project's new home can be found at
https://projects.eclipse.org/projects/ee4j.jpa/releases/3.0-jakarta-persistence-api
An interesting aspect is that no other change whatsoever is allowed; the idea here is that while this is a breaking change, it should be straight forward to upgrade by simply running a replacement script.
To keep our own work simpler, rather than working on a one-off big patch I'll work on testing a replacement script which we could run multiple times at minimal risk; this should make it simpler to forward-port further patches from before the big rename.