We have used Hibernate in OSGi environments in a couple of our projects and it may be useful if I share my thoughts in this topic.

I do not thing you should try implementing the whole part of JPA-OSGi spec. It has many OSGi related issues like: wait for every dependency to be present and start the entityManager than. Dependencies like the TransactionManager, DataSourceFactory or the DataSource as an OSGi service...

There are several projects that do this logic like Aries JPA, Gemini JPA and Everit-JPA (this is my one ). They do not care at all about the provider itself but the only requirement is that an OSGi service has to be registered with the PersistenceProvider interface. In this case the first job is to provide HibernatePersistence class as an OSGi service which is easy to be done with a Bundle-Activator. You can write one more class in the hibernate-entitymanager and take that class into the MANIFEST.MF file under Bundle-Activator. OSGi will not be a dependency than if you are not in an OSGi environment as this class will not be called. If you need an example it is here: https://guest:guest@source.everit.biz:443/svn/everit-osgi/trunk/hibernate/adapter/src/main/java/org/everit/osgi/hibernate/adapter/HibernatePersistenceActivator.java
For this you need only OSGi core as a dependency and it can have scope provided as the OSGi container has to contain it already.

If you use Aries JPA or my one the createContainerEntityManagerFactory will be called on the instantiated HibernatePersistence. The PersistenceUnitInfo will contain the classloader of the PU bundle. PU bundle means the bundle that contains the persistence.xml. The Classloader of the PU bundle should see every entity classes and also the classes that may be used as result classes of queries. Therefore if Hibernate wants to find a class that is not provided by itself it should always be looked by the classloader that is provided in the PersistenceUnitInfo.

It is another topic but I do not think using some magic based class-finding mechanism is a good idea. Anyway, let the provided PersistenceUnitInfo have the already collected data for you and in that case you will not have any problem searching entity classes...

I worked based on these rules and created the two projects hibernate-bundle (that wraps hibernate jars and adds Manifest headers) and the Hibernate adapter project. Hibernate adapter project was necessary as in some cases hibernate uses ContextClassLoader and not the one provided by PersistenceUnitInfo. An example like this is the query result classes.

I do not think you should ever think of Fragment-Bundles. It is very rare where they are useful. You will have serious problems when you want to update the fragment bundles without restarting the server as the host bundle has to be refreshed as well... Always think instead of interfaces and services. Services can have key-value based properties which they can be filtered.