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.s...@gmail.com> wrote: > On Wed, Mar 11, 2020 at 9:49 AM Sanne Grinovero <sa...@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev