Niclas Hedhman wrote:
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.
Yup. Now, in Cocoon's 'sitemap blocks', as Stefano defined them, a block
is identified by its namespace, and blocks depend upon each other via
these namespaces. I'm not yet sure whether we can implement that kind of
dependency management using point 2 above or not. I hope so!
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).
I don't understand quite how this could work. After all, if one bundle
depends upon another, if that bundle includes its dependency within it,
hasn't that killed all benefit? Or must it just include the interface
that its dependency bundle implements? Is that what you mean?
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.
See [1]. I would assume this is R4 syntax, although I can't be sure.
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.
Sorry, don't get why this makes distribution harder.
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.
Doesn't it do this already? How does Maven add something here?
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'.
Yup. Move a few Cocoon devs over to Oscar and get the project going.
Only problem is I haven't managed to get Cocoon to run with Oscar yet :-(
Regards, Upayavira
[1] http://oscar.objectweb.org/oscar-alpha.html#export-filters
