Not sure who you mean by @Chris... Chris Dennis maybe?

Yes, it is master. It is working right now to the degree shown in the very simple test case. So it is picked up and selected properly. Most of its internals are implemented in hibernate-core's org.hibernate.cache.spi.support package, which is already tested in both hibernate-core's test-suite (through the cache provider defined in hibernate-testing) and the hibernate-jcache test-suite. That's why I said you have very little to look at, have a look at how simple it is to define a provider (assuming a "standard" level of support.

IMO this should be moved to the Ehcache project and you can chose to maintain that as long as you think, even as part of the ehcache2 jar. But I'd really like to get out of maintaining these in the Hibernate code base. We are not the subject matter experts and in fact all of the development on these providers have historically been done by the developers of Infinispan and Ehcache. You could take this code I pushed to hibernate-ehcache defining an Ehcache and just move it to your project. We recommend users use "short names" for the cache provider they want to use ("ehcache" and "ehcache-singleton" for Ehcache) rather than class FQN, so this move should not affect users though we all know some probably still use the class FQN - and even that is ok because we register the new ones under all the old one's FQNs so it JustWorks(tm).

This is something I am going to mention on the hibernate-dev mailing list and gauge reaction to.