Am 25.08.2011 um 16:28 schrieb Marshall Schor: > ... > The various existing OSGi tools seem to support multiple styles of creating > bundles: if you have an Annotator that depends on other Jars, you can either > incorporate those Jars within the bundle, or you can depend on them (in the > OSGi > import-package/bundle sense), and keep your bundle small. This latter way > seems > the preferable approach. > ...
I agree that this depending (in the OSGi sense) is the preferable way, but the problem is, that not all jars are available as OSGi bundles. Also, not all OSGi frameworks support that drop-in mechanism for JARs that you explain (I think Equinox has nothing like this). Even if a framework provides such a mechanism, I wonder how is handles cases where I have two annotators A and B depending on the same artifact but in two incompatible versions (e.g. a version 1.x and a version 2.x). Can e.g. Apache Karaf automatically generate proper versions even if the JAR dropped into the folder does not contain any version information at all, so that one is wired to A and the other to B? I like in Maven that it automatically materializes all dependencies on my machine and I do not have to do anything. When I install an OSGi-bundled annotator, the same thing should be the case. It come with all dependencies that are not readily available on Eclipse Update Sites - it may depend on stuff that's available out there and that Eclipse can automatically resolve and download. Unfortunately, I believe that the Eclipse Update Site ecosystem is much smaller than that of Maven. Something that might help here is the Springsource Enterprise Bundle Repository (http://ebr.springsource.com/repository/app/), but lots of stuff is also not covered there (e.g. Tika). While I agree that it's better to depend on libraries, for the most part, I think adding bundling dependencies is more practical for the end user. The alternative would be that the UIMA project offers an Update Site with OSGi-ified versions of the dependencies required by the annotators. I personally would not go down that road though, as I believe it causes lots of work regarding maintenance of such bundles. So far my thoughts. Best, -- Richard -- ------------------------------------------------------------------- Richard Eckart de Castilho Technical Lead Ubiquitous Knowledge Processing Lab FB 20 Computer Science Department Technische Universität Darmstadt Hochschulstr. 10, D-64289 Darmstadt, Germany phone [+49] (0)6151 16-7477, fax -5455, room S2/02/B117 [email protected] www.ukp.tu-darmstadt.de Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de -------------------------------------------------------------------
