Great to see that this goes on the way. Here a few high level considerations ...

#1 Think about the modularity contract first. A bundle has capabilities/requirements. Exported packages are a type of capability. Imported packages a type of requirement.

There are two types of audiences to consider.

#1.1 The set of hibernate artefacts

For each artefact define the set of packages that you want other hibernate artefacts to see. Everything else should be private to the respective artefact and not be exported.

#1.2 User code

It would be possible to expose every hibernate artefact and hence every packages that it exports directly to user code. Alternatively, the set of hibernate artefacts can be aggregated in a different set (or just one) of bundles. This aggregate bundle would only export the packages that are intended to be used by user code. The latter approach could potentially reduce the number of "public" packages by large and such reduce maintenance cost - you only need to worry about backwards compatibility of those.

#2 Pay attention the the OSGi version scheme

OSGi versions that are associated with exported packages have semantic meaning. This needs to be honoured otherwise clients that specify version ranges may not work properly. Also honour this within the set of hibernate artefacts. It should be possible to reason about artefactA and its capabilities/requirements without having to think about artefactB. If you do this properly the individual artefacts become more loosely coupled can be worked on more independently and would overall reduce the maintenance effort.

#3 Work with the Enterprise OSGi JPA spec instead of trying to get Hibernate bundles to work in a Framework in some other way. I'm looking at bringing OSGi JPA to AS7 - it be grate if Hibernate could be the provider

#4 You can always meet me on the forum, irc, dev list or phone if needed. It be great if Hibernate could be part of the JBossOSGi umbrella.

good luck & talk soon
--thomas