We just released Hibernate ORM 5.4.0.Final after two candidate releases.
Thanks to everyone involved in testing the CRs, that was very helpful.
The idea behind 5.4 is to be a drop-in replacement of 5.3.x so please
consider moving to this version as 5.3.x will only receive critical
You can find the full announcement on our blog:
Have a nice day!
I started working on a WildFly change WFLY-11243  to cache the
TransactionSynchronizationRegistry inside of the WildFly JtaPlatform
instance. The purpose of caching the TransactionSynchronizationRegistry
is to avoid repeated JndiService.locate() calls, like during entity
manager creation time  and other uses as well.
My question is whether the idea of caching the
TransactionSynchronizationRegistry instance is already handled at the
session factory level? If not, would that make sense?
 is the WildFly pr to cache the TransactionSynchronizationRegistry
instance, to avoid repeatedly looking it up (since it rarely ever
changes). If there is a way to instead have the
TransactionSynchronizationRegistry cached at the SF level, that might be
Last time we discussed it, it seemed there wasn't any automatic job
regularly publishing ORM 6.0 snapshot artifacts; right now I can see that
the latest snapshot was published on December 5th by Steve himself (not
Jenkins); probably while performing tests for the 6.0.0.Alpha1 release?
So I just created a Jenkins job to publish Snapshot artifacts for ORM 6.0:
It's just a copy of hibernate-orm-master-h2-main with the branch changed to
wip/6.0 and a one-build-per-hour throttle added (we may remove that if you
For now the job is disabled. Steve, do you agree with publishing snapshot
artifacts? Can I enable this job? Do I have to add specific options (ignore
some tests, some modules, ...) to the gradle command in order for the build
to pass? Do you want me to disable build failure notifications?
Snapshots would come in handy to test Hibernate Search 6.0 against ORM 6.0.
For now Search 6 is still using ORM 5.4, because a lot of Search's tests
need association types that are not yet supported in 6, but I'd like to
keep track of progress made on ORM 6 so I can react if further
Hibernate NoORM Team
As I am preparing the Alpha1 release a few topics of discussion have come
Previously (last year's f2f) we had decided to unify the artifact naming
conventions; specifically for ORM this meant renaming the groupId from
`org.hibernate` to `org.hibernate.orm` as part of 6.0. I wanted to see if
everyone still agrees with this.
There are a few artifacts we need to decide how to handle:
- `hibernate-entitymanager` and `hibernate-java8` have been part of
`hibernate-core` since 5.2 (I thought moving `hibernate-entitymanager`
happened way earlier, but seems like not). Should we drop these? They
have been defined as relocations for quite some time now).
- `hibernate-ehcache` defines support for using Ehcache 2 as a
second-level cache, which is a version the Ehcache team does not even
support anymore and have not for quite a few years. Ehcache 3 is a JCache
compliant version and the way that the Ehcache team prefer to handle the
integration (in fact they wrote most of `hibernate-jcache`). IMO this
should be removed as well. Thoughts?
- `hibernate-infinispan` - support for using Infinispan as a Hibernate
L2C has been moved to the Infinispan project. Again, IMO this module should
go away. Thoughts?
Andrea, Chris.. anything you can think of that I missed?
We just published 5.11.0.CR1, the first candidate release for the 5.11
branch. This release mainly includes an upgrade to Hibernate ORM 5.4.0.CR2.
If you want to test it, now is the time!
More info: http://in.relation.to/2018/12/05/hibernate-search-5-11-0-CR1/
Hibernate NoORM Team