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

[Yvan Royon]

On Wed, Sep 24, 2008 at 17:53, Stuart McCulloch [EMAIL PROTECTED] wrote:
 2008/9/24 Yvan Royon [EMAIL PROTECTED]

 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...


Ah, so I should have paid attention to those hundreds of pages after all :)

Well, it's a little disappointing that DeploymentPackages (and p2
Installable Units, from what I gather) are not first-class OSGi
citizens.

What is kind of a breaker is this: Two deployment packages are not
allowed to create or manipulate the same artifact. This means in an
open platform, with multiple software providers, I can't wrap a whole
hypothetical application in a single DeploymentPackage if it includes
standard or widely-used services. I need to carefully identify and
separate some parts of the application from the no-longer-global
package, if I want to play nice with others. And then use an extension
such as OBR to ease the deployment of those remaining parts. That's a
bit of useless complexity, and 2 layers of optional features, for
something quite basic (single-click application deployment, on a
deployment platform...).

I sound trollish, but oh well :)

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

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

[Yvan Royon]

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