like it is today? The difference with the existing cache provider would be the groupId. Or some other artifact id?

to? E.g. assuming we take 'hibernate-infinispan', should it be like that, or should it instead be 'hibernate5-infinispan'? This is where it'd be interesting to hear about our past Lucene directory or Query integration experience.

5. A thing to consider also is whether to maintain same package naming. We're currently using 'org.hibernate.cache.infinispan.*'. From a compatibility sense, it'd help to keep same package since users reference region factory fully qualified class names. We'd also continue to be sole owners of 'org.hibernate.cache.infinispan.*'. However, I dunno whether having 'org.hibernate...' package name within Infinispan repo would create other issues?

time, using JUnit. The testsuite already runs fast enough and I'd prefer not to change anything in this area right now. Is that Ok? Or is there any desire to move it to TestNG?

I think it's going through, we've approved you in the past. Replies below: > On 31 May 2017, at 17:02, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > > Just a heads up - FWIW I doubt my reply goes through to the entire infinispan-dev list. > > Replies inline... > > > 3. What should be the artifact name? Should it be 'hibernate-infinispan' like it is today? The difference with the existing cache provider would be the groupId. Or some other artifact id? > > Since you use Maven (IIUC) you could just publish a relocation... Oh, didn't know about that. Yeah, I think we'd do that: https://maven.apache.org/guides/mini/guide-relocation.html > > > 4. Should the main artifact contain the hibernate major version it belongs to? E.g. assuming we take 'hibernate-infinispan', should it be like that, or should it instead be 'hibernate5-infinispan'? This is where it'd be interesting to hear about our past Lucene directory or Query integration experience. > > 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. > > > 5. A thing to consider also is whether to maintain same package naming. We're currently using 'org.hibernate.cache.infinispan.*'. From a compatibility sense, it'd help to keep same package since users reference region factory fully qualified class names. We'd also continue to be sole owners of 'org.hibernate.cache.infinispan.*'. However, I dunno whether having 'org.hibernate...' package name within Infinispan repo would create other issues? > > FWIW Hibernate offers "short naming" or "friendly naming" for many configurable settings, cache providers being one. For hibernate-infinispan we register 2: "infinispan" and "infinispan-jndi". 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'd just specify "infinispan", "infinispan-jndi", etc. Ah good to know, I wasn't aware of it. I'll look into that. > 6. Testing wise, the cache provider is currently tested one test at the time, using JUnit. The testsuite already runs fast enough and I'd prefer not to change anything in this area right now. Is that Ok? Or is there any desire to move it to TestNG? > > 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? They seem pretty stable to me when I run them locally.