cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: [RT] The impact of using OSGi
Date Mon, 25 Jul 2005 11:51:37 GMT
On Monday 25 July 2005 18:57, Upayavira wrote:

> Well, no, it doesn't. OSGi by default doesn't do any dependency
> resolution. Either by package, or by 'block'. In which case, if we use
> Maven for it at build time, we're still stuck with a need for it at
> deploy time, which seems a little odd.

There are a few issues in play here;
  1. Depending on Services.
  2. Depending on specific bundles.
  3. Depending on Java interfaces, not "owned" by the current bundle.

> Building when you depend on java code in other bundles isn't that easy.
> For one, you may depend upon java classes which are in a jar embedded
> within another jar. 

3. I think it is expected that classes that a Bundle depends on for its on 
instantiation and execution, is distributed with it (or referenced in the 
Manifest to a global resource (probably not recommended but possible).


> Secondly, the bundle you 
> are depending upon might only export some of its classes. Ant can't
> specify only certain classes in its classpath (I dunno if Maven can
> handle this). 

OSGi doesn't Import/Export classes, it only imports/exports packages. And by 
using differnt <path> in Ant, you can make the distinction. 

> So, the only solution we were able to come up with was to 
> explode the dependency bundle's jar, only extracting the exported
> classes/interfaces.

Not sure what you mean here.

It seems to be a common pattern that a Bundle Jar has the "third-party 
dependencies" in embedded Jars, while the classes "owned" by that Bundle sits 
in the Jar root. This makes compiling easy and distribution harder, since you 
probably want the exported classes from a Bundle to be inside your bundle.

I think there is room for a lot of improvement in the global OSGi community 
about this. For instance, exported classes could (should?) be published as 
Maven artifacts, and be referenced in the Manifest as artifact: URLs (I have 
this working locally), and OSGi will resolve at runtime which bundle actually 
exposes the exported classes.

> This seems to me to be an OSGi specific problem, which, to my mind,
> would be best sorted in an OSGi context.

Agree. Cocoon should probably forward "usage issues" to the incubating Oscar 
project, and until that settles, the migration from a single Cocoon bundle to 
use OSGi bundles in Cocoon will be somewhat 'icky'.



Cheers
Niclas

Mime
View raw message