Or more completely "What are the trade-offs and questions that should be raised when trying to decide the bundle structure of an OSGi application?"
Our existing OSGi bundles have tended to be quite fat: basically an API bundle and an implementation bundle, but with a lot of functionality. That has advantages in terms of project and build complexity, but maybe doesn't give us all the reusability and flexibility we desire.
So in a recent project, we intentionally made quite thin bundles. We did a walkthrough this AM and we wondered if we'd gone too far. In this quite-small service we had 7 bundles, several of which only had 1 domain class. The question raised was "This is almost like we're driving towards a bundle per package. But we have classes and packages already in the language, are we going too far with our bundle granularity?"
To make it concrete, this is a Web Service that performs a calculation on the aggregate results of other Web queries (specifically, we query a bunch of astronomical databases for objects in a given area and then we filter the results based on our own criteria and then we estimate a probability of an adequate observation based on the filtered results). We ended up with 7 bundles, which seems like a lot for what is essentially "a servlet that performs a calculation."
Is such very-fine granularity good (lots of flexibility at runtime) or bad (overly complicated)? How can we develop our intuition about the "just right" granularity of our OSGi bundles?