Sorry to bump a 4 month old thread... On Mon, Jun 9, 2008 at 09:18, Peter Kriens <[EMAIL PROTECTED]> wrote: > > The whole problem with modularity is the -granularity-. If you make the > granularity too small you end up with too many artifacts to comprehend. > If you make it too large you do not get the desired mix and match behavior.
Compare this with recursive component models, say, Fractal. Maybe SCA fits the bill also. With these systems you have composite components and unit components. A unit components contains actual code (impl, api, whatever). It can be as small as the developers' smallest unit of reuse. A composite component embeds unit components and/or other composite components. It allows you to package and distribute your code: the whole app is a composite, then inside are composites that relate to different parts in the design of your application, then ... etc. You ony need a single component to deploy the whole application, whether it is a SimpleHttpClient or the whole HugeAndComplex IDE. It is thus much simpler for an end-user or admin to browse a catalogue and to choose an application to deploy. The way I see it, an OSGi bundle tries to fit both granularities at the same time. Thus, it is up to the packager to choose one or the other, or a little of both, and it can be ugly. In my opinion, OSGi (or maybe just OBR and the shell service) needs a way to express "group-of-bundles-that-go-together-to-form-a-useful-app", so that developers and packagers can express both granularities. -- Yvan Royon _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
