[infinispan-dev] missing "int org.infinispan.configuration.cache.EvictionConfiguration.maxEntries()" & NoSuchMethodError running hibernate-infinispan tests with Infinispan 7.2.1

Sanne Grinovero sanne at infinispan.org
Fri May 15 14:54:20 EDT 2015


On 15 May 2015 at 18:16, Scott Marlow <smarlow at redhat.com> wrote:
>
>
> On 05/15/2015 12:43 PM, Sanne Grinovero wrote:
>> Yes the hibernate-infinispan module will need maintenance as usual,
>> but don't bother to update Infinispan in Hibernate 4.3, as WildFly 10
>> has to have Hibernate 5.
>
> This is a valid choice but also means that Infinispan 8 will not work
> with WildFly 10, if Hibernate 5 is not ready in time for the WildFly 10
> release.  I think that we all probably heard that WildFly 10 is supposed
> to be a short release.  Perhaps the involved project leads should
> discuss this (Infinispan/HibernateOrm/WildFly) and sync up on scheduling
> so there are no surprises/last minute integration efforts.

Infinispan doesn't depend on a specific version of Hibernate, so while
I'm pretty sure that Infinispan 8 will be ready on time I don't see
why that would be a problem if - hypothetically - at last minute
WildFly 10 were to pick Infinispan 7 instead.

>> We can focus on the hibernate-infinispan module in branch master only
>> (Hibernate 5), but also let's try to not realize update needs last
>> minute.
>
> To me this is more of a personal preference on how the one person that
> knows how to do the integration (between Infinispan/Hibernate), does
> their work.  But, sure, lets "try".  Perhaps keeping a
> hibernate-infinispan branch up to date Infinispan changes, would be
> helpful.  Galder, I hope these suggestions are helpful and not as
> annoying as I suspect they may be. ;)

It might not be a good idea to update Hibernate to a version of
Infinispan which might not be included, until you're sure. I agree
it's nice to try keeping up - in secondary branches - to make sure one
is aware of what might be needed, and possibly raise issues in
advance. And anyone can start such an experiment.

For sure Galder is the most expert on the module, but with "let's try"
I really meant all of us. This has to be cross-team teamwork.
It's not an unilateral decision of the Hibernate team to pick which
version is being merged in WildFly, and so for Infinispan. WildFly
being the integration, it's up to WildFly to choose a compatible
combination, and that's not necessarily the latest of each.

So while project leads and components leads can give some advice,
ultimately it's up to who needs them to work together who should watch
out, possibly running integration tests and TCKs well in advance to
see integration issues coming. The earlier reported, the better for
all.
Also note that one project *might not want to* depend on the version
which WildFly plans to use.. really WildFly should be prepared to run
his own tests overriding the versions, and I wouldn't advice starting
such a job during CR1.

Thanks,
Sanne


More information about the infinispan-dev mailing list