Intellectual Cramps

Hi,

well, this is not easily answered, depends most on your requirements. We do always start with a few bundles (app, model, ui, ui.api) and split, when necessary, applications usually end up in 30 to 40 different bundles.

Martin

this really depends from so many project-specific dependencies and can only be answered knowing the requirements.

of course some rules are there:

* separate all your tiers (ui, persistence, ...)
* if parts are used at client (per ex. RCP) and also at server-side: divide your bundles, that the client has as less dependencies as possible
* if different developer / architects at different locations are working in the same area it makes perhaps sense to divide the bundles that each can work on his/her bundle
* if you have product families, separate core and domain-specific things
* if there's a part where most of your customers make customization, then a separate bundle can make sense to separate this. (per ex. in some cases I use extra bundles for Enumerations to ease it for customers to add/change them)
* separate bundles where you can imagine that another implementation could be used now or later
* separate bundles if it helps to avoid cycles or buddies
* separate bundles containing business-logic changing often

...only some ideas and hints from my work as software architect for OSGI enterprise apps

ekke

OSGi is basically a mini Service Orientated Architecture. Each Bundle is essentially a self contained mini server running a service that other programs can use. As with any service it should have a well defined purpose and scope. Essentially this approach means that there is a clear separation of concerns.

In other words Bundles are an abstraction above packages. They should have their own service interface, and the implementation should be hidden. Obviously how you handle separation of concerns will determine how many bundles fall out of the design.