Even if you can't think of specific "services" that should be registered with the OSGi Service API, there might still be some that come up. For instance, we had to create "SessionFactoryService" and "PersistenceProviderService", rather than allowing client bundles to directly use our API to get a SF/EMF. That mechanism allows me to bootstrap the OSGi-specific classloading concepts, etc. We were trying to keep all OSGi dependencies within the hibernate-osgi module. Odds are, things like that will become issues in Search as well.

In addition, some of Search's use of ORM extension points may need to change within the OSGi environment. We exposed interfaces like Integrator, TypeContributor, StrategyRegistration, etc. as OSGi registrations.

Packaging is a frustrating issue. You don't want to iterate over all activated bundles to find entities, etc. There's performance considerations, but most importantly that can cause conflicts if multiple versions of a bundle are running. ORM restricts everything to the one bundle: "requestingBundle" (the bundle requesting the SF from the services). There are multiple ways to scope the bundles-to-consider, such as additional manifest values, etc.), but that's what we went with for the time being.

Dynamism is being investigated in ORM with HHH-8501, but definitely isn't supported right now. Dynamically activating/deactivating either Hibernate or client bundles should be considered catastrophic for the time being.