Re: [osgi-dev] Put API/SPI/implementation into separate bundles?

[Jeff McAffer]

Or even something like Equinox's p2 support.  It allows you to publish bundles and collections of bundles and manage dependencies on arbitrary capabilities and requirements.  To a certain degree you can do similar things with OBR it is just harder to create the metadata and the capability namespace is not (AFAIK) extensible.  See     http://wiki.eclipse.org/Equinox/p2 Jeff Stuart McCulloch wrote: 2008/9/24 Yvan Royon <[EMAIL PROTECTED]> 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. perhaps something like this :)    http://www.osgi.org/javadoc/r4/org/osgi/service/deploymentadmin/DeploymentPackage.html although there's still plenty of scope for further development / tooling... -- Yvan Royon _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev -- Cheers, Stuart _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev

_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev