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

Scott Marlow smarlow at redhat.com
Mon May 18 10:28:24 EDT 2015



On 05/15/2015 02:54 PM, Sanne Grinovero wrote:
> 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.

Probably would be better to understand why the hibernate-infinispan 
module is being broken by Infinispan upstream changes and whether a more 
pro-active approach could help.

>
> Thanks,
> Sanne
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>


More information about the infinispan-dev mailing list