All: Did not mean to stirrup all this when I first asked the question :-(
Anyways we managed to "OSGify" Jena. If anybody is interested drop me an email and I can provide direction. It was our resident OSGi expert that did it but I can provide explanation as best as I can, if needed. We did not address, as it was not one of our goals, the need to produce two jars from one set of source code. As somebody already mentioned I would go for simplicity having only one set that contains the manifest entries for OSGi, thus making the jars readily compatible with OSGi, yet still usable outside of it. My 2 cents. Please do not hesitate to contact me if you need additional information. Thank you. Regards, Nikolaos Abatzis New River Systems Corporation 1890 Preston White Drive, Suite 240 Reston, VA 20191 ________________________________________ From: Dave Reynolds [[email protected]] Sent: Friday, April 08, 2011 5:39 AM To: [email protected] Subject: Re: Jena as OSGi bundle This is getting rather off-topic for jena-users so I suggest taking it elsewhere, however rather than leave a dangling set of questions here's a brief response ... On Fri, 2011-04-08 at 09:16 +0100, Ian Dickinson wrote: > > It is perfectly possible to do what Paolo has already done and > > include an OSGi manifest in the jena.jar. That is useful but not as > > useful having a more self contained bundle.[*] > > Sorry, I must be missing something here. I thought that the point of > OSGI was like maven and other dependency managers: No, OSGi is not a dependency manager it's a module system for java. Definitely shouldn't think of it as a weird maven, they are doing different jobs. In Java you end up in jar hell because all the contents of all the jars is normally mixed up in a single namespace (i.e. classloader). Maven et al solve this by helping you pick the jars you are going to put in that global namespace. OSGi (and to some extent other container approaches) solve this by breaking up the global namespace. Encouraging you to write components that expose compact service interfaces and hiding all the implementation details of those components, allowing selective import/export of packages. Then it adds the service layer machinery for how you can advertise, discover link to, dynamically change, inspect, configure etc those services. So there's a choice about how much of the details (including things that were implemented as other jars) you expose from a bundle. You could have every bundle expose every package if you wanted to. There's also a choice about how self-contained your bundles are. Some projects provide both fine grain bundles and all-in-one bundling of those bundles. > that the dependencies > are declarative so that (a) they can be auto-installed by the container, > and (b) duplication can be avoided and conflicts resolved. Better than that, conflicts are to some extent avoided in the first place by allowing multiple versions to coexist and allowing components to be selective in both import and export. > Are you > saying that in an OSGI container, you're still responsible for > installing all the dependencies yourself? Yes, for the basic containers. There are services which can help with that "provisioning" (e.g. PAX runner) including some dependency support (and support for provisioning plain jars and wars) but as a bundle provider you probably don't want to force people to use those. Dave
