<div dir="ltr">Awesome, good to know...<div><br></div><div>About the tests... yes, that is the problem with &quot;intermittent&quot; ;)  You can run it 10 times and then it will break.  Then you run it 500 times and it breaks.  All without any code changes.  But like I said, if that is really fixed... awesome</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jun 2, 2017 at 9:13 AM Galder Zamarreño &lt;<a href="mailto:galder@redhat.com">galder@redhat.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think it&#39;s going through, we&#39;ve approved you in the past.<br>
<br>
Replies below:<br>
<br>
&gt; On 31 May 2017, at 17:02, Steve Ebersole &lt;<a href="mailto:steve@hibernate.org" target="_blank">steve@hibernate.org</a>&gt; wrote:<br>
&gt;<br>
&gt; Just a heads up - FWIW I doubt my reply goes through to the entire infinispan-dev list.<br>
&gt;<br>
&gt; Replies inline...<br>
&gt;<br>
&gt;<br>
&gt; 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>
&gt;<br>
&gt; Since you use Maven (IIUC) you could just publish a relocation...<br>
<br>
Oh, didn&#39;t know about that. Yeah, I think we&#39;d do that:<br>
<a href="https://maven.apache.org/guides/mini/guide-relocation.html" rel="noreferrer" target="_blank">https://maven.apache.org/guides/mini/guide-relocation.html</a><br>
<br>
&gt;<br>
&gt;<br>
&gt; 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>
&gt;<br>
&gt; 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.<br>
&gt;<br>
&gt;<br>
&gt; 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>
&gt;<br>
&gt; 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.<br>
<br>
Ah good to know, I wasn&#39;t aware of it. I&#39;ll look into that.<br>
<br>
&gt; 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>
&gt;<br>
&gt; 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?<br>
<br>
They seem pretty stable to me when I run them locally.<br>
<br>
<br>
<br>
<br>
</blockquote></div>