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 <sa...@hibernate.org>: > On 13 December 2017 at 13:54, Steve Ebersole <st...@hibernate.org> 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 <yo...@hibernate.org> > 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 > >> yo...@hibernate.org > >> > >> On 13 December 2017 at 13:10, Sanne Grinovero <sa...@hibernate.org> > 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@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 > > _______________________________________________ > 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
