[infinispan-dev] Proposal for moving Hibernate 2l provider to Infinispan

Steve Ebersole steve at hibernate.org
Fri Jun 2 10:40:23 EDT 2017


Awesome, good to know...

About the tests... yes, that is the problem with "intermittent" ;)  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


On Fri, Jun 2, 2017 at 9:13 AM Galder Zamarreño <galder at redhat.com> wrote:

> 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 at hibernate.org> 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.
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170602/7c19dce2/attachment.html 


More information about the infinispan-dev mailing list