On 15 March 2018 at 13:04, Steve Ebersole <st...@hibernate.org> wrote: > Given the changes to the second-level cache SPI, I wonder if we want to > take that as an opportunity to consider dropping the `hibernate-ehcache` > module? > > There are a few reasons I am considering this... > > 1. We have the JCache integration in place and users can use Ehcache > via that support already. > 2. This is really the same discussion we had wrt Spring Cache[1]. IMO > the answer should be consistent. We moved hibernate-infinispan for many of > these same reasons... > 3. A large part of the argument for keeping hibernate-ehcache was that > it is already in place and therefore did not require much effort to > support/maintain. However, given the new SPI there is actually a pretty > big effort to adapt hibernate-ehcache to those new SPIs. So far I am the > one doing that - which in and of itself is fine since I am the one who > changed the SPIs ;) But it makes me think it is far less of a maintenance > effort just to drop it and support just hibernate-ehcache.
I guess you meant "support just JCache" ? +1 since the new SPI is different. I do wonder if the JCache API will be a straitjacket for futher performance improvements, but I guess we could re-insert this module if there's more concrete elements? At least any work due to SPI changes could be deferred. We'll still be testing with Ehcache - over JCache - I hope? Thanks, Sanne > > WDYT? > > > [1] https://github.com/hibernate/hibernate-orm/pull/1639 > _______________________________________________ > 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
