Following Steve's suggestion using resolutionStrategy, I was able to build the
hibernate-infinispan jar with Infinispan 6.0.0.Final and run the unit tests with
7.2.1.Final.
I'm sure there's a more elegant way to do this, so I've created a new jira
(HHH-9802) and a pull request with the change I made:
https://github.com/hibernate/hibernate-orm/pull/955 .
There were actually some unit test failures in InfinispanRegionFactoryTestCase using
7.2.1.Final due to java.lang.NoSuchMethodError.
It happens in assertions like:
assertEquals(5000, cacheCfg.eviction().maxEntries());
The problem is that org.infinispan.configuration.cache.EvictionConfiguration.maxEntries()
returns int in 6.0.0.Final, but returns long in 7.2.1.Final. The only usage I see is in
the unit tests. I can probably workaround this in the unit test, but I was wondering if
this could cause a problem if an application used this method directly.
Galder, do you know if this is a concern?
I have instructions in the pull request for reproducing these failures.
I commented out the failing assertions locally to verify that nothing else causes the test
to fail.
I also see org.hibernate.cache.infinispan.TypeOverrides.evictionMaxEntries is defined as
an int. That gets initialized based on a value set for on
hibernate.cache.infinispan.<classnam>.eviction.max_entries. The only place I see
TypeOverrides.getEvictionMaxEntries() used is in InfinispanRegionFactoryTestCase. Does
this actually get used anywhere? Does the value find its way into a
EvictionConfiguration.maxEntries field? If so, should be a long (instead of an int) in
master?
I had a quick chat with Scott Marlow when I realized this was a potential problem and we
agreed that it shouldn't block releasing Hibernate ORM 4.3.10.Final. I have gone ahead
and released 4.3.10.Final.
I will check in on things Friday morning, but I have to leave by 10:30am and will be off
the rest of the day. I can pick this up on Monday if need be.
Regards,
Gail