NoClassDefFoundError: Could not initialize org.hibernate.tool.version

Question

I'm trying to reverse engineer my Oracle Database with Hibernate Tools. However, when I try to do so, I get the following error:

Received a NoClassDefFoundError, propably the console configuration classpath is
incomplete or contains conflicting versions of the same class.
java.lang.NoClassDefFoundError: Could not initialize org.hibernate.tool.version

I read that something like this could happen due to a conflict between the Hibernate Tools Jar and the regular Hibernate Jars. I removed my Maven-Import and manually added the Hibernate-Jar (only the core-jar like described in the solution).
I'm using the Development Milestone 4.0.0 of Hibernate Tools , I put the Hibernate-version in the tools configuration to 4.0 and I used the current Hibernate 4.1.7. I also tried the Hibernate 4.0.0-Core-Jar but with every combination I got the same error.
Oh, and I use STS 3.1.0 (don't think it's that however).

Any tips/suggestions would be appreciated.

Answer 1

Ok, found the error: I tried various versions and finally hibernate-annotations-3.5.6 worked. Must have been some weird combination that produced the error. Thanks for your answers anyway.

Answer 2

It was a matter of removing some hibernate 3.6 jars which were apparently conflicting with the hibernate-tools plugin's own jars.

Here's what you need to do to successfully reverse engineer the database tables without getting the errors i got:

you must have in the project build path only the hibernate3.jar and the jdbc driver (postgresql-9.0-blabla.jar), the others (antlr, dom4j, slf4j, jta,etc.) should be removed; i have not tried to reverse-engineer in JPA mode but i reckon you'll have to keep the hinernate-jpa-2.0-api-blabla.jar in your project's build path.

After you finished using hibernate-tools plugin you must include the other jars because otherwise the hibernate code won't work ( i think, i haven't tested yet, but if the documentation for 3.6 says so... )

Answer 3

I've seen the same error but in a completely different context when using cxf generated java stubs against a web service that had a newer version of WSDL, when that happens the SOAP response may have xml elements that CXF (or somethign else) would try to serialize into java classes/objects and may throw this error when the java class corresponding to the new element in the SOAP response isn't anywhere to be found.

The moral of the story, please make sure that the version of the java client (the set of jars that include stubs) you are using is compatible with the service provider.