Perhaps the best approach would be to try something like this, but in a way that would not affect the non-OSGI packaging.
The base UIMA code does this, for instance, by having the plain Jars, and then having a uimaj-ep-runtime project, which takes (some of) those same Jars and runs the Felix Maven bundle plugin to generate the manifest. As I recall, due to the fact that some Eclipse dependencies existed for the Eclipse-based tooling, and Eclispe had "split-packages" (the same package use in multiple jars, each contibuting some classes), it was quite tricky (took some trial and error) to get the bundle plugin to go. All this was documented in the dev-list, and some summary was put onto the wiki. I recommend that you take a try at making uimaj-as-ep-runtime plugin (or several, if you think one per uimaj-as jar is more appropriate). (We started using the -ep- in the name to indicate it's an OSGi plugin. Of course, the initial meaning of this was "Eclipse Plugin" - but that's not really so accurate anymore as there are now alternate popular OSGi "containers"... so maybe a better convention for naming these would be good. I would suggest .... -osgi- .... (I like obvious things :-) ) -Marshall Jörn Kottmann wrote: > Jaroslaw Cwiklik wrote: >> Jörn, the Uima AS client is dependent on: >> >> spring >> saxon >> activemq >> uima-core >> uimaj-as-core >> uimaj-as-jms >> uimaj-as-activemq >> >> If the client needs to communicate with a service via http protocol, >> there >> are additional/optional jars >> but I think you are using tcp protocol to connect to a broker. >> >> As far as OSGi, I dont think this is on our plate now. >> > Would you support adding an osgi manifest.mf to the > uimaj-as-xxx jars ? This could be done with the maven felix > bundle plugin. I could help out here. > > For uimaj-as-core and uimaj-as-jms it easy but for > uimaj-as-activemq it is a bit tricky because it has so > many dependencies like derby which I doubt it really needs. > > Jörn > > > >
