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 >>
