As I am preparing the Alpha1 release a few topics of discussion have come up... Previously (last year's f2f) we had decided to unify the artifact naming conventions; specifically for ORM this meant renaming the groupId from `org.hibernate` to `org.hibernate.orm` as part of 6.0. I wanted to see if everyone still agrees with this.

There are a few artifacts we need to decide how to handle: - `hibernate-entitymanager` and `hibernate-java8` have been part of `hibernate-core` since 5.2 (I thought moving `hibernate-entitymanager` happened way earlier, but seems like not). Should we drop these? They have been defined as relocations for quite some time now).

- `hibernate-ehcache` defines support for using Ehcache 2 as a second-level cache, which is a version the Ehcache team does not even support anymore and have not for quite a few years. Ehcache 3 is a JCache compliant version and the way that the Ehcache team prefer to handle the integration (in fact they wrote most of `hibernate-jcache`). IMO this should be removed as well. Thoughts?

- `hibernate-infinispan` - support for using Infinispan as a Hibernate L2C has been moved to the Infinispan project. Again, IMO this module should go away. Thoughts?

Andrea, Chris.. anything you can think of that I missed? _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Hi, I also agree with Christian. For the `hibernate-entitymanager`, the problem came from Spring as they wanted to support multiple versions of Hibernate. I wrote them on Twitter about this change so that they can adjust their framework to accommodate it. Vlad On Wed, Dec 5, 2018 at 3:53 PM Christian Beikov < christian.beikov(a)gmail.com&gt; wrote: > Am 05.12.2018 um 14:42 schrieb Steve Ebersole: > > As I am preparing the Alpha1 release a few topics of discussion have come > > up... > > > > Previously (last year's f2f) we had decided to unify the artifact naming > > conventions; specifically for ORM this meant renaming the groupId from > > `org.hibernate` to `org.hibernate.orm` as part of 6.0. I wanted to see > if > > everyone still agrees with this. > +1 > > There are a few artifacts we need to decide how to handle: > > > > - `hibernate-entitymanager` and `hibernate-java8` have been part of > > `hibernate-core` since 5.2 (I thought moving > `hibernate-entitymanager` > > happened way earlier, but seems like not). Should we drop these? > They > > have been defined as relocations for quite some time now). > +1 for dropping the relocation artifacts > > - `hibernate-ehcache` defines support for using Ehcache 2 as a > > second-level cache, which is a version the Ehcache team does not even > > support anymore and have not for quite a few years. Ehcache 3 is a > JCache > > compliant version and the way that the Ehcache team prefer to handle > the > > integration (in fact they wrote most of `hibernate-jcache`). IMO > this > > should be removed as well. Thoughts? > Sounds reasonable. > > - `hibernate-infinispan` - support for using Infinispan as a > Hibernate > > L2C has been moved to the Infinispan project. Again, IMO this module > should > > go away. Thoughts? > +1 as well > > Andrea, Chris.. anything you can think of that I missed? > > _______________________________________________ > > 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

One other artifact note... `hibernate-envers` has been merged into `hibernate-core` as of 6. Should we just drop this one since this is a new major release? Or do the relocation for a few? On Wed, Dec 5, 2018 at 7:42 AM Steve Ebersole <steve(a)hibernate.org&gt; wrote: > As I am preparing the Alpha1 release a few topics of discussion have come > up... > > Previously (last year's f2f) we had decided to unify the artifact naming > conventions; specifically for ORM this meant renaming the groupId from > `org.hibernate` to `org.hibernate.orm` as part of 6.0. I wanted to see if > everyone still agrees with this. > > There are a few artifacts we need to decide how to handle: > > - `hibernate-entitymanager` and `hibernate-java8` have been part of > `hibernate-core` since 5.2 (I thought moving `hibernate-entitymanager` > happened way earlier, but seems like not). Should we drop these? They > have been defined as relocations for quite some time now). > - `hibernate-ehcache` defines support for using Ehcache 2 as a > second-level cache, which is a version the Ehcache team does not even > support anymore and have not for quite a few years. Ehcache 3 is a JCache > compliant version and the way that the Ehcache team prefer to handle the > integration (in fact they wrote most of `hibernate-jcache`). IMO this > should be removed as well. Thoughts? > - `hibernate-infinispan` - support for using Infinispan as a > Hibernate L2C has been moved to the Infinispan project. Again, IMO this > module should go away. Thoughts? > > > Andrea, Chris.. anything you can think of that I missed? > >

Another one.. `hibernate-orm-modules` defines a `hibernate-envers` module (in the WF modules sense). Since envers is now part of `hibernate-core` should we remove that module or have it just act as an alias for the main orm module?

On Wed, Dec 5, 2018 at 7:54 AM Steve Ebersole <steve(a)hibernate.org&gt; wrote: > One other artifact note... > > `hibernate-envers` has been merged into `hibernate-core` as of 6. Should > we just drop this one since this is a new major release? Or do the > relocation for a few? > > On Wed, Dec 5, 2018 at 7:42 AM Steve Ebersole <steve(a)hibernate.org&gt; wrote: > >> As I am preparing the Alpha1 release a few topics of discussion have come >> up... >> >> Previously (last year's f2f) we had decided to unify the artifact naming >> conventions; specifically for ORM this meant renaming the groupId from >> `org.hibernate` to `org.hibernate.orm` as part of 6.0. I wanted to see if >> everyone still agrees with this. >> >> There are a few artifacts we need to decide how to handle: >> >> - `hibernate-entitymanager` and `hibernate-java8` have been part of >> `hibernate-core` since 5.2 (I thought moving `hibernate-entitymanager` >> happened way earlier, but seems like not). Should we drop these? They >> have been defined as relocations for quite some time now). >> - `hibernate-ehcache` defines support for using Ehcache 2 as a >> second-level cache, which is a version the Ehcache team does not even >> support anymore and have not for quite a few years. Ehcache 3 is a JCache >> compliant version and the way that the Ehcache team prefer to handle the >> integration (in fact they wrote most of `hibernate-jcache`). IMO this >> should be removed as well. Thoughts? >> - `hibernate-infinispan` - support for using Infinispan as a >> Hibernate L2C has been moved to the Infinispan project. Again, IMO this >> module should go away. Thoughts? >> >> >> Andrea, Chris.. anything you can think of that I missed? >> >> _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

> > - `hibernate-entitymanager` and `hibernate-java8` have been part of > `hibernate-core` since 5.2 (I thought moving `hibernate-entitymanager` > happened way earlier, but seems like not). Should we drop these? They > have been defined as relocations for quite some time now). > So it's a detail but it's pretty handy to have relocations for these artifacts in the case of our test case template as we can test various versions without changing anything. If it's not a nightmare, I would keep them.

> - `hibernate-ehcache` defines support for using Ehcache 2 as a > second-level cache, which is a version the Ehcache team does not even > support anymore and have not for quite a few years. Ehcache 3 is a > JCache > compliant version and the way that the Ehcache team prefer to handle > the > integration (in fact they wrote most of `hibernate-jcache`). IMO this > should be removed as well. Thoughts? > Last release was 2.10.6 of October 2018. So it's still alive. I know we have users still using it.

If JCache covers all the features we had before, we could remove it and see how people reacts to it. It would still be time to reinject it later if someone comes up with a very compelling use case. And be done with it, if not.

- `hibernate-infinispan` - support for using Infinispan as a Hibernate > L2C has been moved to the Infinispan project. Again, IMO this module > should > go away. Thoughts? > No opinion here.

On Wed, Dec 5, 2018 at 4:47 PM Steve Ebersole <steve(a)hibernate.org&gt; wrote: > On Wed, Dec 5, 2018 at 9:28 AM Guillaume Smet <guillaume.smet(a)gmail.com&gt; > wrote: > >> So it's a detail but it's pretty handy to have relocations for these >> artifacts in the case of our test case template as we can test various >> versions without changing anything. >> >> If it's not a nightmare, I would keep them. >> > > Define nightmare ;) > > As for "test case templates", that is code we write/control - so not > understanding that point. > When someone uses our test case template, I often check if the issue also applies to previous versions. Often helps to narrow down the issue. If artifacts are consistent across versions, it's easier. It's convenient, not required. > Last release was 2.10.6 of October 2018. So it's still alive. I know we >> have users still using it. >> > >> If JCache covers all the features we had before, we could remove it and >> see how people reacts to it. It would still be time to reinject it later if >> someone comes up with a very compelling use case. >> >> And be done with it, if not. >> > > Not sure what to tell you about a new release aside from saying that we > often continue to release very old versions of ORM even though we do not > support them. The existence of a release does not mean it is supported. I > have been told by the Ehcache developers that version 2 has not been > supported for many years (and that was almost a year ago). Interpret that > how you want I guess. > > As for users still using it, that is a documentation issue imo. I had > discussed this with Vlad previously that we ought to prefer > hibernate-jcache + ehcache 3 in the documentation, but it looks like that > has not happened. Vlad? > Let's agree to agree on this one and remove it :). > > >> - `hibernate-infinispan` - support for using Infinispan as a Hibernate >> >> >>> L2C has been moved to the Infinispan project. Again, IMO this module >>> should >>> go away. Thoughts? >>> >> >> No opinion here. >> > > I am curious. Why is this different to you compared to > hibernate-ehcache. To me it is the same exact situation. > It's mostly the "If JCache covers all the features we had before" I mentioned above that makes the difference. For Infinispan, we decided JCache was good enough. As for Ehcache, I'm wondering it all the features are exposed. The other thing is that I don't really know when the Infinispan code has been moved so I don't know if it's too early to remove it without relocation or not. So, no opinion :). -- Guillaume

> - `hibernate-infinispan` - support for using Infinispan as a Hibernate > L2C has been moved to the Infinispan project. Again, IMO this module should > go away. Thoughts? About this one, and the `hibernate-envers` you mentioned in previous email, it would be nice to help people a little more. Especially Envers's integration as it just happened.

distracted by such details at this stage - we can always add a truckload of such metadata later according to feedback - even beyond a 0.Final

Similarly the WildFly modules I contributed just recently :-/ .. feel free to remove those, we'll see to re-introduce support as needed, and IF needed. I'd propose to ignore OSGi headers as well - not sure of the consequences though, so let's keep it IF it's not too much of a burden. We can re-introduce support and tests in a later feature release.