I started creating the layout for the hibernate-ogm-ehcache module.
Now I stumbled on something, given I'm no maven expert, I think might
not be quite right:
from the parent project, it couldn't resolve the dependency to
hibernate-ogm-core, so I first had to install that from the
./hibernate-ogm-core module, so I could build from the root.
I think this might not be what is wanted though ... Is there a reason
for that ? Or is this some weirdness I experience because I used mvn2
Otherwise I started the module on my fork on github and will work to
get something passing tests as soon as possible.
Thanks a lot for all these changes!
PS: Also, I started using my Hibernate-core code style, but look like
this might use another, right ?
On Sun, Dec 4, 2011 at 7:21 PM, Sanne Grinovero <sanne(a)hibernate.org> wrote:
we've implemented all changes in Hibernate OGM which we discussed at
Devoxx to make it easier for you to create a new module and get
started experimenting with an EHCache integration.
Actually to proof myself correct I've already created a new module,
and removed Infinispan from the main module relegating it in it's own
extension; so while in the main pom and possibly in some comments and
documentation Infinispan might still be mentioned as the "main"
supported engine, it's not the case anymore as far as the
implementation concerns: the tests of the core module are now using a
"spiced" ConcurrentHashMap instead and we'll improve on the docs too
as soon as we actually have an alternative. I hope this will let you
get started quickly, basically you only have to look into the
Infinispan module and think how to best implement the 6 trivial
The structure of the testsuite might need some warnings: since the
tests verify the functionality via the user API, we actually want to
re-run all the tests on each database. That's what Hibernate Core
always did, via a couple of properties it switches the JDBC driver and
connection details, just one class cares for the dialect which
encapsulates the database specifics; but most code is well tested
using a single database, so by default the testsuite runs H2 only,
while Jenkins re-runs the full testsuite on all supported databases.
In the case of Hibernate OGM, the code which we actually want to test
is the integration with each database, so running tests on only one of
them is not really an option.
To re-run the same testsuite multiple times, and to keep all the
database specific code and dependencies in different modules, we're
hacking a bit around Maven by packaging the testsuite from the main
module and referring to the same tests again in each module.
Basically I'd suggest to have a look at how the
hibernate-ogm-infinispan module reuses the test code from
hibernate-ogm-core; most of the magic is triggered by the
maven-dependency-plugin in the parent pom.xml and the
org.hibernate.ogm.test.utils.InfinispanTestHelper in the test sources.
Of course you can add additional EHCache tests as you like in the new
hibernate-ogm-ehcache module, but I'd suggest to reuse all tests from
We can certainly polish this approach if it doesn't proof sound in
practice, but I hope it's a good way to get started with it. It should
provide some convergence of features across "databases"; if some
feature can really not be implemented we can introduce flags to
disable groups of tests in specific modules; for now there exists one
such flag which disables JTA integration  : I'm using it with the
Map implementation as I didn't implement transactional support on it.
In theory you could introduce more such flags if you really need to
disable some other tests, but that would be the least desirable option
as we hope to provide a consistent behaviour across different backing
databases as much as possible.
The basic build information can be found here:
For any question, we're looking forward to help you!
1 - org.hibernate.ogm.test.utils.TestableGridDialect.backendSupportsTransactions()
Alex Snaps <alex.snaps(a)gmail.com>
Senior Software Engineer - Terracotta