In doing this I have realized that there are quite a few cases of split packages where two (sometimes three or more) projects have classes in the same package. This is important for the OSGi packaging because package names are the primary descriptor for importing and exporting code from bundles and if more than one bundle exports from the same package there is quite a bit more work to maintaining the packaging configuration (in this case, a plugin config in the pom.xml). One big example is the org.apache.directory.server.core.partition.* packages which are contained in multiple partition implementations as well as apacheds-core.
We have the same "issue" (if we can call that an issue) in Studio...
Sometimes some plugins, the 3 plugins of the LDAP Browser for example, contribute classes to the same package.
For us, it's not such a big deal. The only need we had to do is provide the correct configuration for the Felix Bundle plugin in terms of imported and exported packages.
So my first question is if this is something that we want to discuss and start taking care of now? There are several solutions obviously, and it is quite possible that we can work around this with hand crafted packaging descriptors for the OSGi bundles. This is a bit of work however and long term maintenance of the packaging will be much higher. Other options include re-organizing packages to have more unique structure (my personal preference), or we could also combine some of the scattered code into consolidated jar files.
Re-organizing packages to have more unique structure is also my personal preference and it implicates some important refactoring. But for sure, this would help a lot when reviewing code. Sometimes it takes me some time to find where a specific class is hidden in the various projects.
The idea of consolidated jar files is something that can be acheived more easily. Actually, we already have an "apacheds-all" artifact that should contain all the ApacheDS code.