"bstansberry(a)jboss.com" wrote : Re: the tests, there are tests in the Hibernate 3.3 core cache-jboss-cache2 module that avoid using the AS. See the org.hibernate.test.cache.jbc2.functional package. The difficulty is those bring in dependencies on the Hibernate test module, plus I'm sure have JBC 2 ties. So it will require some effort to break those ties and let them run standalone. I've started looking at the dependencies on the test module. Hibernate 3.2.x never produced any binaries with the test classes required to port the org.hibernate.test.cache.jbc2.functional tests. Since 3.3.x though, such jar has been made available (http://repository.jboss.org/maven2/org/hibernate/hibernate-testing/3.3.0....). I've done a diff between the test classes in 3.2.x and trunk and they're almost identical with a few minor differences such as: use of org.slf4j rather than commons logging, and refactoring of DummyConnectionProvider and DummyTransactionManagerLookup into ConnectionProviderImpl and TransactionManagerLookupImpl. There's also a 2 of extra methods in UnitTestCase (createFailureExpectedSuite() method), FunctionalTestCase (isSerializableIsolationEnforced() method) and removed FunctionalTestClassTestSuite(String) constructor from FunctionalTestClassTestSuite. Bottom line: I think I can safely add a dependency for HB 3.3 hibernate testing even though we're testing HB 3.2.x. WDYT? This would much easier than having to now come up with testing jars for 3.2.x series. The downside here is that if we pull 3.3 hibernate testing module, we're indirectly pull other jars but I don't see any direct incompatibilities with what we pull right now for 3.2.x: M2_REPO/junit/junit/3.8.1/junit-3.8.1.jar | M2_REPO/antlr/antlr/2.7.6/antlr-2.7.6.jar | M2_REPO/commons-collections/commons-collections/3.1/commons-collections-3.1.jar | M2_REPO/dom4j/dom4j/1.6.1/dom4j-1.6.1.jar | M2_REPO/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar | M2_REPO/javax/transaction/jta/1.1/jta-1.1.jar | M2_REPO/org/slf4j/slf4j-api/1.4.2/slf4j-api-1.4.2.jar I think it'd be interesting to get Steve's thoughts on this. Thoughts? "bstansberry(a)jboss.com" wrote : On the name, how about "hibernate-jbc-cache-provider"? CacheProvider is the legacy API that's replaced in 3.3. Including it in the name is at least a small indication this is a legacy integration. I like the name, just one little thing. To make the legacy aspect even more obvious, I'd suggest making cache-provider a single word, matching the class CacheProvider class name: i.e. hibernate-jbc-cacheprovider. As an extension of this, I suppose the package name for this classes would be something along: org.jboss.hibernate.jbc.cacheprovider View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4165540#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...