Thanks Marshall for summarizing things :) 2011/7/20 Marshall Schor <m...@schor.com>
> 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) > it seems so and I wasn't aware of that > > 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). > > +1 > 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 :-) . > cool :) we should work together to define an accurate proposal to implement in a major version of UIMA > > 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? as highlighted by Florent they are used (as SNAPSHOT dependencies) in Clerezza and Stanbol and, as long as I can see, they seem to be working. Once we go through the steps defined in point 2) I'd add them to the current release. > Would it even work if we removed the UIMA framework > itself from being included in each OSGi bundle of an add-on annotator? I successfully tried it with Apache Felix starting first the uimaj-ep-runtime then starting the annotators' bundles and then starting (and using the services of) a third bundle which depends on them. Is it > only usable with the Eclipse-buddy style of embedding? > on Apache Felix it worked also without the current configuration using Eclipse-buddy style: <Eclipse-ExtensibleAPI>true</Eclipse-ExtensibleAPI> <Eclipse-BuddyPolicy>registered</Eclipse-BuddyPolicy> thus using the default OSGi one. In the end my opinion is that we should fix the current bundles as highlighted by Marshall, include them in the 2.3.1 addons release and then define a roadmap for a better OSGi support (we could use the wiki to collect proposals/pros/cons/etc. ). My 2 cents, Tommaso > > -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 > >>> >
