uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tommaso Teofili <tommaso.teof...@gmail.com>
Subject Re: UIMA, Maven & OSGi, modularity
Date Thu, 01 Sep 2011 12:34:20 GMT
Hi all,
just for your information at Clerezza we're discussing on how to proceed
with using the current 2.3.1 Addons annotators inside an OSGi environment
[1].
I think that could be a nice 'benchmark' for future UIMA and OSGi related
developments.
My 2 cents,
Tommaso

[1] :
http://www.mail-archive.com/clerezza-dev@incubator.apache.org/msg05420.html

2011/8/25 Marshall Schor <msa@schor.com>

>
>
> On 8/25/2011 2:06 PM, Richard Eckart de Castilho wrote:
> > Am 25.08.2011 um 16:28 schrieb Marshall Schor:
> >
> >> ...
> >> The various existing OSGi tools seem to support multiple styles of
> creating
> >> bundles: if you have an Annotator that depends on other Jars, you can
> either
> >> incorporate those Jars within the bundle, or you can depend on them (in
> the OSGi
> >> import-package/bundle sense), and keep your bundle small.  This latter
> way seems
> >> the preferable approach.
> >> ...
> > I agree that this depending (in the OSGi sense) is the preferable way,
> but the problem is, that not all jars are available as OSGi bundles. Also,
> not all OSGi frameworks support that drop-in mechanism for JARs that you
> explain (I think Equinox has nothing like this).
>
> Karaf and pax-construct both allow specifying different OSGi frameworks -
> they're "outside" the framework.  So, for instance, they can work with
> Equinox.
> The Karaf overview page says "Supports the latest OSGi 4.2 containers:
> Apache
> Felix Framework 3.0 and Eclipse Equinox 3.6".
>
> > Even if a framework provides such a mechanism, I wonder how is handles
> cases where I have two annotators A and B depending on the same artifact but
> in two incompatible versions (e.g. a version 1.x and a version 2.x). Can
> e.g. Apache Karaf automatically generate proper versions even if the JAR
> dropped into the folder does not contain any version information at all, so
> that one is wired to A and the other to B?
> I don't know.
>
> I think pax-construct uses pom information when getting Jars from Maven to
> supply this, though.
> >
> > I like in Maven that it automatically materializes all dependencies on my
> machine and I do not have to do anything.
>
> +1
> > When I install an OSGi-bundled annotator, the same thing should be the
> case.
>
> +1
> > It come with all dependencies that are not readily available on Eclipse
> Update Sites - it may depend on stuff that's available out there and that
> Eclipse can automatically resolve and download.
>
> +1
> > Unfortunately, I believe that the Eclipse Update Site ecosystem is much
> smaller than that of Maven. Something that might help here is the
> Springsource Enterprise Bundle Repository (
> http://ebr.springsource.com/repository/app/), but lots of stuff is also
> not covered there (e.g. Tika).
>
> One other feature available in pax-construct is the ability to treat maven
> repos
> as if they were OSGi repos.  See:
> http://www.sonatype.com/books/mcookbook/reference/ch01s04.html
>
> They have examples of importing both OSGi bundle things, and non-OSGi
> dependencies.
> >
> > While I agree that it's better to depend on libraries, for the most part,
> I think adding bundling dependencies is more practical for the end user. The
> alternative would be that the UIMA project offers an Update Site with
> OSGi-ified versions of the dependencies required by the annotators. I
> personally would not go down that road though, as I believe it causes lots
> of work regarding maintenance of such bundles.
>
> +1 to not going down that road :-)
>
> -Marshall (who's not actually tried any of this :-) )
> >
> > So far my thoughts.
> >
> > Best,
> >
> > -- Richard
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message