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
