Steve Ebersole I can (but should I?) give my opinion with you on this… But I'm not the one responsible for any of this (anymore), keep this in mind

I think dropping does makes sense:

• From hibernate's perspective:
  • jcache provides most probably sufficient initial support "out of the box" for users (as far as I can remember at least);
  • why bother introducing dependency other libraries and with each's lifecycle, given the above!
• From ehcache's perspective (or any other vendors really) :
  • bundling a fined tuned provider, possibly using private APIs (e.g. the things we've done in the past for TC clustered H2LCs), will always tie tighter with the caching-provider than with hibernate;
  • for a majority of uses cases (read in-mem single node deploys) the jcache provider will do the job;
  • why bother having a split code-base to its lifecycle, given the above!

That being said, I'd probably rip this out… in a major version maybe? Dunno. Also, this obviously needs synching with the TC folks to make sure the alternative path is available at the latest on that hibernate release, which ever that is. Again, something I no longer have any control on… My $.02, but SEP Shields back up Don't know who on TC's end is best to commit on any of this? Chris Dennis, care to point finger?