that's right, there is a class bundled for hibernate 3.3 support, but it should get loaded (referenced) only if you're using hibernate 3.3. See line 490 of this file:
Hibernate 3.2.4 and 3.2.6 should work fine. The exception doesn't contain to much information, there's nothing more above that? I've run the tests on 3.3 and they worked, though it's not an OSGi environment.
Hrm - if org.jboss.envers.entity.VersionsInheritanceEntityPersisterFor330 was in its own package I could simply exclude that from my OSGi bundle, as it is - OSGi picks up the class and pulls in a requirement for org.hibernate.cache.access
For now a workaround I can do is to manually delete that class from the jar file.
Ah, so OSGi scans the jar and loads every class? I guess I'll just provide two packages, for hibernate 3.2.x and 3.3.x. For now, if you're building from source, you can simply comment out the second < javac > task from the "build" target in build.xml (line 136)
OSGi itself doesn't do this, but the bnd tool used to help managing your manifest files does.
OSGi works by Importing/Exporting packages from various bundles, the bnd tool is scaning the jar and finding this class and added to the manifest that the package uses org.hibernate.cache.access.
This in turn triggers the OSGi framework so stand up and shout "hey, something in your bundle uses/needs xxx, but its not here...".
A separate package would be great - thanks.