I'm unsure of the merit of supporting both JPA 2.2 and JPA 3.0 using the
exact same source code and jars.
I have not thought too much about the ramifications of this, but what about
dealing with this by having the gradle build generate JPA 3.0-compatible
source/test code, then changing the release process to test/release both
JPA 2.2-compatible and JPA 3.0-compatible sets of jars, source code, and
documentation?
The JPA 2.2-compatible jars could follow our current naming conventions.
The JPA 3.0-compatible jars could have a suffix like <version>-JPA3.jar.
I believe this would be less work than employing bytecode magic.
Users would have the ability to move to using JPA 3.3 with 5.3/5.4.
Obviously this would have ramifications for WildFly/EAP.
Anyhow, that's my half-baked idea...
Regards,
Gail
On Wed, Mar 11, 2020 at 7:43 AM Guillaume Smet <guillaume.smet(a)gmail.com>
wrote:
On Wed, Mar 11, 2020 at 9:49 AM Sanne Grinovero
<sanne(a)hibernate.org>
wrote:
> I'm not a fan of bytecode hacks either, so maybe let's just see what a
POC
> looks like before tearing it down?
>
>>
I totally miss why we would want to even work on a POC given how much we
have on our shoulders? Could someone explain it to me?
IMHO, *if* consumers of our stack want to support both javax and jakarta
packages, the work will need to be done there i.e. in WildFly or Quarkus.
There's a good chance the solutions will be different given the totally
different infrastructure of both.
And supporting that for Hibernate ORM only makes sense if the whole stack
supports that e.g. CDI, HV, Jakarta EL... and AFAICS most of the projects
will only support either javax or jakarta, not both. So if we want to
support both, we will need the extra layer I was talking about at a global
level, not in Hibernate ORM.
I wouldn't open the door at supporting both in ORM and let the consuming
projects decide of the strategy they want to follow and how they want to
solve the issue globally.
--
Guillaume
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev