Looks like the general agreement is that we will no longer need - https://github.com/hibernate/hibernate-jpa-api As we're switching to the standard API distribution, finally available: javax.persistence:javax.persistence-api:2.2 Still I expect there's going to be some confusion about this, e.g. Scott was asking today in chat where to find our custom API at versions 2.2. I'd like to deploy a relocation artifact so that people merely upgrading the version to 2.2 of their dependency to org.hibernate.javax.persistence will get an automated warning and be nicely redirected to the new artifact. Any objections? The one problem I can see is that in case we need to patch it we'd need to restore the org.hibernate.javax.persistence and it might get messy, but I think we can agree the chance for this need to arise being extremely small. Thanks, Sanne _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Considering the spec contracts are defined by the EG under the JCP, I'm not sure where we ever stood legally with publishing this under any other license. Either way, I am not concerned about the license aspect - I think it is a reasonable expectation that if I am using a jar produced by a spec that use of that jar is covered by the JCP under which it was produced.

Sanne, my concern about publishing the relocation artifact is that the expectation is that we keep publishing them ever time there is a new spec version. Right?

On Wed, Dec 13, 2017 at 6:47 AM Yoann Rodiere <yoann(a)hibernate.org&gt; wrote: > > Seems like the right thing to do. I'm just concerned about the license. Is > it identical? > Some people might be upset to get a new dependency pulled "automatically" > if it has a stricter license... > > Yoann Rodière > Hibernate NoORM Team > yoann(a)hibernate.org > > On 13 December 2017 at 13:10, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > > > Looks like the general agreement is that we will no longer need > > - https://github.com/hibernate/hibernate-jpa-api > > > > As we're switching to the standard API distribution, finally available: > > javax.persistence:javax.persistence-api:2.2 > > > > Still I expect there's going to be some confusion about this, e.g. > > Scott was asking today in chat where to find our custom API at > > versions 2.2. > > > > I'd like to deploy a relocation artifact so that people merely > > upgrading the version to 2.2 of their dependency to > > org.hibernate.javax.persistence will get an automated warning and be > > nicely redirected to the new artifact. > > > > Any objections? > > > > The one problem I can see is that in case we need to patch it we'd > > need to restore the org.hibernate.javax.persistence and it might get > > messy, but I think we can agree the chance for this need to arise > > being extremely small. > > > > Thanks, > > Sanne > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev

Just to be sure, including an EPL-licensed item is fine as far as WildFly is concerned? Other than that, +1 for that change.

2017-12-13 14:04 GMT+01:00 Sanne Grinovero <sanne(a)hibernate.org&gt;: > > On 13 December 2017 at 13:54, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > > Considering the spec contracts are defined by the EG under the JCP, I'm > > not > > sure where we ever stood legally with publishing this under any other > > license. Either way, I am not concerned about the license aspect - I > > think > > it is a reasonable expectation that if I am using a jar produced by a > > spec > > that use of that jar is covered by the JCP under which it was produced. > > +1 > Also, we'll be switching to use the official ones anyway. That's an > orthogonal concern, my goal with this thread is to sunset our custom > fork with least possible friction, but it's not going to live much > longer for sure. > > > Sanne, my concern about publishing the relocation artifact is that the > > expectation is that we keep publishing them ever time there is a new > > spec > > version. Right? > > Not really. Think of it as Deprecation: it will trigger some warnings > for end users, especially those who didn't get the "news" of moving to > the new API, and keep things working for a little longer for those > people not willing (able?) to react right away to resolve the > warnings. > > We can keep a deprecated method (jar) around for a couple more > releases, or drop it as soon as it gets too inconvenient to maintain. > It's definitley not a promise of long term. > > > > > On Wed, Dec 13, 2017 at 6:47 AM Yoann Rodiere <yoann(a)hibernate.org&gt; > > wrote: > >> > >> Seems like the right thing to do. I'm just concerned about the license. > >> Is > >> it identical? > >> Some people might be upset to get a new dependency pulled > >> "automatically" > >> if it has a stricter license... > >> > >> Yoann Rodière > >> Hibernate NoORM Team > >> yoann(a)hibernate.org > >> > >> On 13 December 2017 at 13:10, Sanne Grinovero <sanne(a)hibernate.org&gt; > >> wrote: > >> > >> > Looks like the general agreement is that we will no longer need > >> > - https://github.com/hibernate/hibernate-jpa-api > >> > > >> > As we're switching to the standard API distribution, finally > >> > available: > >> > javax.persistence:javax.persistence-api:2.2 > >> > > >> > Still I expect there's going to be some confusion about this, e.g. > >> > Scott was asking today in chat where to find our custom API at > >> > versions 2.2. > >> > > >> > I'd like to deploy a relocation artifact so that people merely > >> > upgrading the version to 2.2 of their dependency to > >> > org.hibernate.javax.persistence will get an automated warning and be > >> > nicely redirected to the new artifact. > >> > > >> > Any objections? > >> > > >> > The one problem I can see is that in case we need to patch it we'd > >> > need to restore the org.hibernate.javax.persistence and it might get > >> > messy, but I think we can agree the chance for this need to arise > >> > being extremely small. > >> > > >> > Thanks, > >> > Sanne > >> > _______________________________________________ > >> > hibernate-dev mailing list > >> > hibernate-dev(a)lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev

On Wed, Dec 13, 2017 at 7:05 AM Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > > Not really. Think of it as Deprecation: it will trigger some warnings > for end users, especially those who didn't get the "news" of moving to > the new API, and keep things working for a little longer for those > people not willing (able?) to react right away to resolve the > warnings. > > We can keep a deprecated method (jar) around for a couple more > releases, or drop it as soon as it gets too inconvenient to maintain. > It's definitley not a promise of long term. Couple more releases of what? Hibernate ORM, as opposed to JPA? I assume that's what you meant, just making sure. Honestly I would never publish a new relocation - that means we are incrementing the version of the JPA API jar, which should not happen.