I found a few things, concerning Eclipse-buddyPolicy on the web. [1] describes it, [2] says it isn't implemented in Felix and won't be, because it causes problems (with GC and other things), [3] is a general discussion of workarounds.
We actually put one of these kinds of workarounds into UIMA for logging [4], although not in an OSGi context. However [5] notes that that workaround has issues, and that the proposal for adding this to OSGi itself, "fell out of the specification for OSGi R4 V4.2 core specification." I think this needs more careful thinking :-) ... -Marshall [1] http://wiki.eclipse.org/index.php/Context_Class_Loader_Enhancements [2] http://markmail.org/message/2smf5ntjhzwalkmm#query:+page:1+mid:epvakx66wz5auvmu+state:results [3] http://njbartlett.name/2010/08/30/osgi-readiness-loading-classes.html [4] https://issues.apache.org/jira/browse/UIMA-1714 [5] http://www.mail-archive.com/equinox-dev@eclipse.org/msg03304.html On 7/20/2011 4:15 PM, Marshall Schor wrote: > Here's my summary of this thread, so far: > > 1) there's lots of interest in OSGi for UIMA components (annotators, shared > type > systems, shared resources) > > 2) the current addon-osgi packaging should be altered: > 2a) to have individual dependent Jars which are not otherwise available as > OSGi bundles, included as Jars, not unpacked, so they don't overlay one > another > 2b) to add OSGi *dependencies* for the base UIMA framework, instead of > including it in every bundle. > 2c) to remove unneeded dependencies from the OSGi packaging (for instance, > the > many apparently extra Jars in the ConfigurableFeatureExtractor OSGi > packaging). > > 3) longer-term: need to come up with a proposal for better OSGi support, as > the > current one only works with Eclipse-buddy kinds of things (which is not > official > OSGi). This new support should be along the lines of enabling UIMA framework > itself, and annotators, to be OSGi components, to be run within any one of a > number of OSGi containers. > Installation should be as easy as dropping a new annotator into a special spot > in the file system :-) . > > 4) I didn't really hear a consensus on actually *releasing* the OSGi bundles > of > the add-ons; is there any real use expect of this kind of packaging with the > current state of things? Would it even work if we removed the UIMA framework > itself from being included in each OSGi bundle of an add-on annotator? Is it > only usable with the Eclipse-buddy style of embedding? > > -Marshall > > On 7/19/2011 6:51 PM, Marshall Schor wrote: >> Moving this from the RC4 release discussion to a new thread ... >> >> I've now tried the following: >> >> Change the build instructions so >> >> a) the dependency goal doesn't unpack the jars >> b) the OSGi build instruction doesn't say to "inline" the jars. >> >> The result - it builds, no error messages, and has a result which includes >> lots >> of Jars at the top level, plus a META-INF directory, and nothing else. >> >> I tried this with the ConfigurableFeatureExtractor-osgi project. The Jars >> that >> get included are all the ones shown by giving the command: mvn >> dependency:tree >> in the project directory. There are many jars, including all of Ant, the >> Ant-launcher Jar, a bunch of eclipse jars including things like >> org.eclipse.core.jobs, the junit jar, and more. Many of these are >> unnecessary, >> I think, and including them in the distribution causes us to work to verify >> the >> appropriate LICENSEs/NOTICEs are created. >> >> It seems very unlikely that the CFE needs all these to run, normally. >> Running >> the non-OSGi CFE maven dependency:tree does not show the ant dependency - >> I'll >> have to track down why those are different. Looking at the 2.3.0 release, >> the >> CFE non-OSGi had many fewer included Jars. >> >> I think we can fix the build instructions to excluded the unneeded Jars. >> >> I don't have any setup for testing the OSGi packaged artifacts - if anyone >> else >> does, let's figure out how to test these - either by collaborating or by >> helping >> me learn how to setup something locally to test this packaging result. >> >> -Marshall >> >> >> >> >> >> >> >> On 7/19/2011 3:44 PM, Marshall Schor wrote: >>> Thanks, Richard. >>> >>> I think you are right - some of the dependencies (for example, the >>> AlchemyApiAnnotator depends on Apache commons-digester, etc.) don't have >>> OSGi >>> packagings. >>> >>> The build strategy for the OSGi modules currently gets all the dependencies >>> and >>> unpacks them into .../target/classes directory, where a later step "jars" >>> them up. >>> >>> This approach overlays files being unzipped, with later versions. Some >>> examples >>> where this might be an issue: >>> There is at the top level a license directory, containing one "LICENSE" >>> file. >>> There is at the top level a "plugin.xml" file. >>> There is at the top level a META-INF dir, with LICENSE and NOTICE files >>> among >>> other things. >>> >>> Perhaps it would be better to package the dependencies that are not OSGi in >>> a >>> way that doesn't need to unpack, and then potentially overlay, files. >>> >>> It seems that OSGi and the bundle plugin support this, via the >>> Embed-Dependency >>> instruction. Is there a reason we're not using that, instead of the >>> "unpacking" >>> approach? >>> >>> -Marshall >>> >>> On 7/19/2011 11:17 AM, Richard Eckart de Castilho wrote: >>>> I wanted to package the DKPro Core UIMA modules as OSGi bundle. These have >>>> lots of dependencies on various JARs that are not available as OSGi >>>> bundles and sometimes not even available in public Maven repositories - >>>> this is why we set up a public repository of our own for the moment. It >>>> may be less an issue for the UIMA sandbox, as the individual components >>>> may not depend on third-party libraries. >>>> >>>> Looking the Add Ons repository, I would suspect that Tika, Solr, Rhino, >>>> BeanShell and maybe some of the Apache Commons JARs may not be OSGi >>>> bundles. >>>> >>>> I guess you aim for a mixed setup where some dependencies (namely UIMA) >>>> are imported via package-imports and others (namely the above) are >>>> packaged inside the bundles? >>>> >>>> Cheers, >>>> >>>> Richard >>>> >>>> Am 19.07.2011 um 17:08 schrieb Marshall Schor: >>>> >>>>> I suspect that the Jars are now available as OSGi bundles; do you know of >>>>> specific ones that are not? >>>>> >>>>> Thanks. -Marshall >>>>> >>>>> On 7/19/2011 10:24 AM, Richard Eckart de Castilho wrote: >>>>>> Hi Marshall, >>>>>> >>>>>> I am very interested in this. Some time back I mostly gave up on >>>>>> packaging UIMA components as OSGi bundles because of this. If you do not >>>>>> bundle all jars (*jikes*) and use package imports instead, the questions >>>>>> is: where do the dependencies come from? Who prepares the bundles and >>>>>> who installs them? Many JARs are not available as OSGi bundles. >>>>>> >>>>>> -- Richard >>>>>> >>>>>> Am 19.07.2011 um 16:13 schrieb Marshall Schor: >>>>>> >>>>>>> I'll take a look at the OSGi build. >>>>>>> >>>>>>> -Marshall >>>>>>> >>>>>>> On 7/17/2011 12:16 PM, Marshall Schor wrote: >>>>>>>> Since this is (I think) the first time we're releasing the OSGi >>>>>>>> packaging of the >>>>>>>> annotators, I think some work on their license/notice files might be >>>>>>>> needed, >>>>>>>> because: >>>>>>>> >>>>>>>> - there are duplicate License files - one at the top level, and one in >>>>>>>> the >>>>>>>> META_INF directory >>>>>>>> - both of these are the plain vanilla license files. For projects >>>>>>>> which are >>>>>>>> incorporating other libraries which are under other than the Apache v >>>>>>>> 2.0 >>>>>>>> license, those licenses have to be included. >>>>>>>> - the NOTICE file is present in the META_INF directory, but is the >>>>>>>> plain one, >>>>>>>> rather than the project specific one. >>>>>>>> >>>>>>>> Finally, I wonder if the OSGi packaging strategy is correct - in that >>>>>>>> it >>>>>>>> "bundles" every dependency into the OSGi file. This certainly makes >>>>>>>> the file >>>>>>>> easier to use, but if a user uses 2 OSGi components from UIMA, won't >>>>>>>> there be a >>>>>>>> lot of unnecessary duplication (or does OSGi notice this and avoid it >>>>>>>> somehow)? >>>>>>>> I'm not sure of an alternative, but I do recall that OSGi allows for >>>>>>>> dependencies on other packages; perhaps that could be useful? >>>>>>>> >>>>>>>> -Marshall >>>>>>>> >>>>>>>> On 7/15/2011 8:29 AM, Tommaso Teofili wrote: >>>>>>>>> Hi all, >>>>>>>>> I've prepared the new RC (4) for UIMA Addons release. >>>>>>>>> >>>>>>>>> The following is a list of issues addressed in this release: >>>>>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310570&version=12316093 >>>>>>>>> >>>>>>>>> The source zip and binary files are available here: >>>>>>>>> http://people.apache.org/~tommaso/uima-addons-2.3.1-rc4 >>>>>>>>> >>>>>>>>> SVN Tag Checkout: >>>>>>>>> svn co >>>>>>>>> http://svn.apache.org/repos/asf/uima/addons/tags/uima-addons-2.3.1-rc4/ >>>>>>>>> >>>>>>>>> Please cast your vote for UIMA Addons 2.3.1 release: >>>>>>>>> >>>>>>>>> [ ] +1 Approve the release >>>>>>>>> [ ] -1 Veto the release (please provide specific comments) >>>>>>>>> [ ] 0 Don't care >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Tommaso >>>>>>>>> >>>> Richard Eckart de Castilho >>>>
