I’ve written before about the problems which seem to crop up when you introduce Hibernate into your project. Unfortunately, I’m becoming more and more convinced that these are not isolated issues. Hibernate has a dependency management problem.
Things were not always this way. Hibernate was once independent, unbeholden to outside influences. Sure, you’ve always needed a somewhat-thicker-than-average skin in order to file bugs or ask questions in the forums. An extra helping of patience never hurt, either. But nowadays it seems like you need all of these things, plus the time and skill necessary to patch a JAR or two.
We recently upgraded to the latest Hibernate production JARs: Hibernate Core 3.2.6.GA, Hibernate Annotations 3.3.0.GA and Hibernate EntityManager 3.3.1.GA. Having already benefited from our earlier experience regarding conflicts between Spring and Hibernate, I figured this would take about five minutes: modify our root Maven2 POM, do a full build, verify everything works. Done! Not quite.
The first problem we encountered, reported 4 months ago, is that the production Hibernate EntityManager POM excludes a transitive dependency which it should not exclude. Net result? You have to hack together a custom version of Hibernate EntityManager which does not exclude this transitive dependency. Of course, this transitive dependency exists in the JBoss Maven2 repo, but not in the central repo. Nice.
Next, if you’re using a standard Maven2 Windows installation, you’ll run into this bug, because Hibernate now refuses to load JARs from directories with spaces in them (the standard location for Maven2 local repositories in Windows is in “Documents and Settings”). Very nice. Welcome to 1998!
You may notice a trend here: an old ASM dependency which causes conflicts with other libraries, a required dependency that is mistakenly excluded, and a dependency on a deprecated class in a buggy JBoss utility library.
Two of my co-workers are already suggesting we switch to TopLink. Jokingly, of course. For now. Napoleon is reputed to have said that “if they want peace, nations should avoid the pin-pricks which precede cannon shots.” Third-party libraries should likewise avoid annoying their users with irritating minutiae, or they may find these users mobilizing the artillery.
Peter Thomas said,
March 12, 2008 at 10:22 am
I think not moving to JPA and sticking to “legacy” Hibernate was a good idea.
Graeme Rocher said,
March 12, 2008 at 2:55 pm
Your problem has nothing to do with Hibernate, but rather that flawed tool Maven 2. Nothing beats managing your own jars
John Greeley said,
March 12, 2008 at 3:14 pm
That’s only half true; the problem may not have to do with the hibernate libraries directly, but it does have to do with the half-baked management of the metadata that the hibernate team publishes to the repositories (both in its own private JBoss repos and the central maven repos).
Of course you can rightly claim that the whole design of the maven dependency management is fatally flawed, but I seem to notice plenty of projects who leverage maven with excellent success while others screw it up royally. And this seems to be far more dependent on the team behind the project rather than the complexity of the technology they are creating.
It seems to me that JBoss doesn’t even bother testing the majority of things it publishes to the maven repositories. The only worse offenders are the Sun projects at java.net who actually seem interested in figuring out ways of to make using maven completely impossible. On the other hand the Spring team has a pretty good track record at publishing reasonable maven metadata even though they don’t even use it as a build tool for their core project.
Despite the flaws in maven, this type of problem reveals the differences in quality control between different project teams. At least Grails avoids maven altogether rather then confusing the issue by supporting it only halfway.
Daniel Gredler said,
March 12, 2008 at 5:08 pm
I actually think Maven2’s dependency management rocks. Like John, I think that the Hibernate metadata which the Hibernate team publishes (in the form of POMs) is their responsibility. They’re doing a sloppy job.
Peter said,
March 12, 2008 at 6:10 pm
Take a look at EclipseLink – Toplink is OpenSource now!
Jason Carreira said,
March 13, 2008 at 12:03 pm
@Daniel, if you think Maven2 dependency management rocks, it means you haven’t tried the other options… Try Ivy, for example, and you’ll see how dependency management should be done.
Also, don’t depend on 3rd parties to define or manage the meta-data. Create your own, and manage your own repository. It’s a little more work up front, but it’s a lot less hassle over the long run.
Daniel Gredler said,
March 14, 2008 at 11:39 am
@Jason: I knew unqualified praise for Maven would get me in trouble!
Can you give (or do you have a link to) a concise explanation of how transitive dependency management is better in Ivy than in M2?