Hello Marshall, Richard, I've been offline for a couple of days, so first of all, sorry for my late reply. Regarding Marshall's comments on Addons distribution package 1. the <mavenExecutorId>forked-path</mavenExecutorId> option has been set up to avoid Maven/shell lockings while signing artifacts as reported on Maven mailing list [1] 2. I agree the NOTICE file contents in the binary distribution package should be improved 3. I thought pdf version of doc was enough for the binary distribution, if we want html version too I'm +1 for modifying the binary assembly descriptor to achieve that 4. Regarding the OSGI things I'll reply on the related thread just after this mail
I'll rollback this RC now. Thanks all for your comments and feedback. Regards, Tommaso [1] : http://markmail.org/message/xvj3q6wgmlgqhz6l 2011/7/19 Marshall Schor <m...@schor.com> > 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 > > >
