I spent time today to have an Hibernate 
example running as Eclipse Plug-ins. Here is a trick to avoid NoClassDefFoundError when using Hibernate within Eclipse.
I have three Plug-ins :
com.mydomain.hibernate: Packaging of the hibernate Jar library in a Plug-incom.mydomain.Acom.anotherdomain.B
These plugins have the following dependencies :
com.mydomain.hibernatedepends on nothing (it’s a “library” Plug-in)com.mydomain.Adepends onBand oncom.mydomain.hibernatecom.anotherdomain.Bdepends on nothing
The NoClassDefFoundError(org.hibernate.proxy.HibernateProxy) was fired when trying to map (in a database using hibernate of course) a class of com.anotherdomain.B in com.mydomain.A code.
The Eclipse ClassLoader mechanisms and the injection of new code from Hibernate in the com.anotherdomain.B are responsible for this error .
Here is THE article that helped me to understand what was happening here and to solve my problem using Eclipse-BuddyPolicy.
The problem with Eclipse-BuddyPolicy is that it doesn’t scale. As long as you have a few domain plug in that’s fine, but when the numbers are starting to get higher, you really don’t want to have to load all you domain plug in to start using your application.
Another way to solve this problem, even if it is a bit more involved is to use Spring dynamic module (aka spring OSGI) which allows to wire the plugins at runtime, only when you need them.
Hi Manuel,
We’ve been working on packaging EclipseLink (JPA, JAXB, SDO) as OSGi bundles and in our Proof of Concept we were able to avoid the use of Equinox Buddy ClassLoading Policy. If you’re looking for high performance persistence you should check out EclipseLink (www.eclipse.org/eclipselink) and our OSGi proof of concept (http://wiki.eclipse.org/EclipseLink/Development/OSGi_Proof_of_Concept).
EclipseLink will be available as OSGi bundles in the 1.0 release.
–Shaun