On 7/20/2011 5:04 AM, Tommaso Teofili wrote:
> Hello all,
> I think a bit of history is helpful here to track what has been done so far
> and what/where we can improve on OSGi components.
Good idea!
> the first thing I used to drive me through the setup of UIMA Addons OSGi
> bundles was the dependency:tree on the non-OSGi version of each component
> which I used to define the initial set of dependencies.
> At first I used the maven-bundle-plugin to produce the OSGi jars (bundles)
> and I deployed them inside an Apache Felix instance.
I think I'm missing the big picture, here. UIMA is usually used as a container
in which Annotators are loaded.
What does it mean to "deploy" inside of an Apache Felix instance? For instance,
can you put together a several annotators and a flow controller (a UIMA
Aggregate) and "run" it inside Apache Felix? I don't see how that is done, when
every Annotator is its own OSGi bundle. Maybe it's because it's early morning
here, and I'm not quite awake, and I've missed the basics ...
This may be all wrong-headed - but I wonder if the basic use case is to do
something like the following: Take a bunch of annotators (and maybe flow
controllers) together with a top-level aggregate XML specifying parameter
overrides, etc., and "wrap" them so they become a single OSGi bundle, that can
then be embedded in an OSGi container? If so, then perhaps instead of having a
"set" of individually OSGi-i-fied annotators, like we do now, maybe we should
have instead a tool that does this for a set of annotators, etc.
> The bundle plugin had one issue with the OSGi version as 2.3.1-SNAPSHOT is
> not a valid OSGi version while it has to be converted to 2.3.1.SNAPSHOT.
We have this problem elsewhere, and use the ${parsedVersion.osgiVersion} in the
poms, to get the version with the period instead of the dash.
> This problem was resolved setting the artifact packaging to jar thus
> creating the bundle using also other plugins (i.e.:
> maven-dependency-plugin).
> On the other hand when deploying those artifacts on Apache Felix I couldn't
> find "a lot" of dependencies not listed by the mvn depdendency:analyze , for
> some of them I could avoid adding an additional dependency by setting an
> "optional import" (i.e. see some sun.* import set to optional) to the bundle
> configuration but this was not possible for every "unexpected" dependency.
> The above issues drove addons-osgi-runtime configurations as they are now.
The ConfigurableFeatureExtractor non-OSGi pom doesn't have an "ant" dependency,
while the OSGi version of that same annotator does. Any idea why this was added
to the OSGi one?
The full list of jars pulled into that annotator's OSGi packaging is quite
large:
ant-1.7.1.jar
ant-launcher-1.7.1.jar
common-2.3.0-v200706262000.jar
common-3.3.0-v20070426.jar
commons-beanutils-1.8.2.jar
commons-collections-3.2.1.jar
commons-jxpath-1.3.jar
commons-logging-1.1.1.jar
ConfigurableFeatureExtractor-2.3.2-SNAPSHOT.jar
contenttype-3.2.100-v20070319.jar
ecore-2.3.0-v200706262000.jar
geronimo-stax-api_1.0_spec-1.0.1.jar
jdom-1.0.jar
jobs-3.3.0-v20070423.jar
jVinci-2.3.1.jar
org.eclipse.core.jobs-3.5.0.v20100515.jar
org.eclipse.equinox.common-3.6.0.v20100503.jar
org.eclipse.equinox.preferences-3.2.1.jar
org.eclipse.equinox.registry-3.5.0.v20100503.jar
org.eclipse.osgi-3.2.1.jar
osgi-3.3.0-v20070530.jar
preferences-3.2.100-v20070522.jar
registry-3.3.0-v20070522.jar
runtime-3.2.0-v20060603.jar
uimaj-adapter-vinci-2.3.1.jar
uimaj-core-2.3.1.jar
uimaj-cpe-2.3.1.jar
uimaj-document-annotation-2.3.1.jar
uimaj-ep-runtime-2.3.1.jar
uimaj-tools-2.3.1.jar
xercesImpl-2.8.1.jar
xmi-2.3.0-v200706262000.jar
xml-apis-1.3.03.jar
xml-resolver-1.2.jar
xmlbeans-2.4.0.jar
-Marshall
> However I do agree with one thing, we should leave out all the dependencies
> which are OSGi compliant or have an OSGi package version.
> If we could revert back to use only the maven-bundle-plugin may help us keep
> things cleaner.
> I'd be happy to help set up a testing environment (this makes me think it'd
> be useful to setup some integration tests) .
> Tommaso
>
> 2011/7/20 Marshall Schor <m...@schor.com>
>
>> 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
>>>>
