Personally I'm now leaning to just adopt the "big bang" approach like
Hibernate Validator did, and other specs are doing, as Guillaume
passionately reminded me we have a lot on our plates - and beyond
doing this work we'd need many tricky integration tests.
However as usual we need to keep some op
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
On Wed, Mar 11, 2020 at 9:49 AM Sanne Grinovero 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
On Wed, 11 Mar 2020 at 12:16, Yoann Rodiere wrote:
>
> > Yet I'm convinced that having a release
> > which provides full JPA 3.0 TCK between 5 and 6 (or however it gets
> > renamed) would be no good to us, as it would create an adoption
> > barrier for both cathegories of people: the ones not inte
When y'all talk about the bytecode enhancement solution, I'd like to better
understand what you mean exactly.
Do you mean at run-time like we did for ORM when we combined
Session/EntityManager? The problem there is that this only works when we
control the environment (WildFly e.g.). Do you mean
On Wed, 11 Mar 2020 at 08:39, Yoann Rodiere wrote:
> > Yet I'm convinced that having a release
> > which provides full JPA 3.0 TCK between 5 and 6 (or however it gets
> > renamed) would be no good to us, as it would create an adoption
> > barrier for both cathegories of people: the ones not inter
> Yet I'm convinced that having a release
> which provides full JPA 3.0 TCK between 5 and 6 (or however it gets
> renamed) would be no good to us, as it would create an adoption
> barrier for both cathegories of people: the ones not interested to
> migrate away from JPA2, and the ones not intereste
On Tue, Mar 10, 2020 at 7:12 PM Sanne Grinovero wrote:
> The "big bang" approach that Validator implemented is an option as
> well; but the context is a bit different as we're having an actual
> major release being developed, and the matter of possible time
> pressure.
>
Thus the proposal of Yoa
I didn't mean to suggest that we fully implement both JPA 3.x and JPA
2.y in any one version.
I'm really just focusing on those principles I mentioned; the main ones being:
- don't spend ages on this effort
- don't add pressure on ORM 6
- not getting in the way of eventual ORM6 adoption
What h
I'm curious... why are we saying that we need to simultaneously support
both sets of annotations and config settings?
As a user, if I choose to use the Jakarta-based JPA I would fully expect
that to only work with the Jakarta-based annotations and settings.
Is there something in the spec I am mis
Hi,
On Tue, Mar 10, 2020 at 2:48 PM Yoann Rodiere wrote:
> > In particular I wonder, how would you all feel if (for example)
> > Hibernate ORM 5.5.x were to depend on both JPA 2 and JPA 3 API
> > artifacts?
>
> Mixed feelings, to be honest
Same here. I thought we decided against supporting bot
Hello,
> In particular I wonder, how would you all feel if (for example)
> Hibernate ORM 5.5.x were to depend on both JPA 2 and JPA 3 API
> artifacts?
Mixed feelings, to be honest:
- It feels there's a high chance we'll waste our time on something
nobody needs. Who in their right mind woul
Hey,
I guess it should be doable to have a dependency on and implement both
APIs but I'm afraid you can't do that with plain Java, you need a build
tool to introduce these bridge methods with possible conversions.
I have been using the following tool in the past to support multiple
versions of
Hi Christian,
On Tue, 10 Mar 2020 at 11:33, Christian Beikov
wrote:
>
> Hey,
>
> do you think it is feasible to create a separate artifact that is a
> bytecode rewriting of the main artifact, replacing javax.persistence by
> jakarta.persistence. This should be no big deal as e.g. the Maven Shade
Hey,
do you think it is feasible to create a separate artifact that is a
bytecode rewriting of the main artifact, replacing javax.persistence by
jakarta.persistence. This should be no big deal as e.g. the Maven Shade
Plugin does that as well. We would only need to accept additonal
poperties li
Hi all,
as a consequence of having moved all Java EE technologies to the
Jakarta EE project at the Eclipse foundation, the API needs to change
so to address the Oracle trademark requirements.
The new JPA project lives here:
- https://github.com/eclipse-ee4j/jpa-api
For context, to make it simpl
16 matches
Mail list logo
