<div dir="ltr">Just a heads up - FWIW I doubt my reply goes through to the entire infinispan-dev list.<div><br></div><div>Replies inline...<br><div><br></div></div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">3. What should be the artifact name? Should it be &#39;hibernate-infinispan&#39; like it is today? The difference with the existing cache provider would be the groupId. Or some other artifact id?<br></blockquote><div><br></div><div>Since you use Maven (IIUC) you could just publish a relocation...</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">4. Should the main artifact contain the hibernate major version it belongs to? E.g. assuming we take &#39;hibernate-infinispan&#39;, should it be like that, or should it instead be &#39;hibernate5-infinispan&#39;? This is where it&#39;d be interesting to hear about our past Lucene directory or Query integration experience.<br></blockquote><div><br></div><div>Probably, but (no promises) one thing I wanted to look at since Hibernate baselines on Java 8, is to maintain the existing SPI using default methods as a bridge.  But failing that, I think your suggestion is the best option.</div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">5. A thing to consider also is whether to maintain same package naming. We&#39;re currently using &#39;org.hibernate.cache.infinispan.*&#39;. From a compatibility sense, it&#39;d help to keep same package since users reference region factory fully qualified class names. We&#39;d also continue to be sole owners of &#39;org.hibernate.cache.infinispan.*&#39;. However, I dunno whether having &#39;org.hibernate...&#39; package name within Infinispan repo would create other issues?<br></blockquote><div><br></div><div>FWIW Hibernate offers &quot;short naming&quot; or &quot;friendly naming&quot; for many configurable settings, cache providers being one.  For hibernate-infinispan we register 2: &quot;infinispan&quot; and &quot;infinispan-jndi&quot;.  You can see this in org.hibernate.cache.infinispan.StrategyRegistrationProviderImpl.  That approach will continue to work when you move it.  The point being that users do not specify the class name in config, they&#39;d just specify &quot;infinispan&quot;, &quot;infinispan-jndi&quot;, etc.</div><div> <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">6. Testing wise, the cache provider is currently tested one test at the time, using JUnit. The testsuite already runs fast enough and I&#39;d prefer not to change anything in this area right now. Is that Ok? Or is there any desire to move it to TestNG?<br></blockquote><div><br></div><div>Hmmm, that is actually surprising... I thought the hibernate-infinispan  provider tests were still disabled as they had routinely caused intermittent failures of the build.  I guess this was rectified?</div><div><br></div></div></div>