uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tong Fin (JIRA)" <uima-...@incubator.apache.org>
Subject [jira] Commented: (UIMA-1027) Classes from uima-document-annotator.jar are not in Eclipse plugin
Date Tue, 13 May 2008 21:01:56 GMT

    [ https://issues.apache.org/jira/browse/UIMA-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596532#action_12596532

Tong Fin commented on UIMA-1027:

Please read the attached text from the uima dev-mailing list with the subject:
    [UIMA eclipse plugins] Possible WRONG wiring between UIMA Eclipse plugins

------------------------------ Copy from uima dev-mailing list --------------------------------
This issue is not unique to OSGi. The package name collision can be happen also to the Java
program that uses multiple Jar(s) in the classpath.

Having "Import-packages+Provider Selection" is not well supported by Eclipse's tooling and
(I think) can be over-designed.

Since this is a "rare" situation that can be occurred among the developers in the "org.apache.uima"
domain, I have the tendency to keep the current specification as it is. Maybe, we just document
it as a reminder at somewhere (just in case there are some plugins that re-define the "org.apache.uima.jcas.tcas").

- Tong
- Hide quoted text -

On Fri, Mar 14, 2008 at 4:58 PM, Marshall Schor <msa@schor.com> wrote:

    OSGi does provide a mechanism to have the import-package include
    specifying which bundle it should come from.  See section 3.6.8
    "Provider Selection" in the r4.core.pdf doc for OSGi for details.

    The POMs we use don't generate this though.  Do you see that allowing
    multiple bundles to export the same package name, and then having our
    configuration be more explicit about which bundle to wire to, is (or may
    be) a design requirement?


    Tong Fin wrote:
    > Hi,
    > The current UIMA Eclipse plugins (runtime, CDE, etc.) use "Imported
    > Packages" for declaring dependencies instead of "Required Plug-ins". This
    > declaration is automatically generated by Maven (I think ?) and gives more
    > fine grained controls on what to depend on.
    > But, there are some side-effects from this approach which may cause the
    > problems. The imported packages may wired to the correct packages from the
    > "wrong" plugins.
    > Today, while I am testing the new UIMA build candidate 03 with my plugins, I
    > had this "wrong" wiring situation. The following is what happen:
    >   -  One of my plugins has two exported packages named "org.apache.uima.util"
    > and "org.apache.uima.jcas.tcas" which are the same as the packages exported
    > by "org.apache.uima.runtime".
    >   -  UIMA runtime plugin (org.apache.uima.runtime) exports "
    > org.apache.uima.util" and "org.apache.uima.jcas.tcas" packages and it also
    > imports these two packages.
    >   -  UIMA CDE plugin uses some classes (e.g., XMLizable) from "
    > org.apache.uima.util" which is imported by using "Imported Packages"
    > approach.
    >   -  At runtime, Eclipse OSGi has the following wiring:
    > id    State       Bundle
    > 0    ACTIVE      org.eclipse.osgi_3.3.1.R33x_v20070828
    > 1    ACTIVE      org.eclipse.equinox.common_3.3.0.v20070426
    > 2    ACTIVE      org.eclipse.update.configurator_3.2.101.R33x_v20070810
    > 3    ACTIVE      org.eclipse.core.runtime_3.3.100.v20070530
    > 4    ACTIVE      org.apache.uima.desceditor_2.2.2.incubating
    > 5    <<LAZY>>    org.apache.uima.editors.dde_2.2.2.incubating
    > 232    <<LAZY>>    org.apache.uima.jcas.jcasgenp_2.2.2.incubating
    > 233    <<LAZY>>    org.apache.uima.pear_2.2.2.incubating
    > 234    RESOLVED    org.apache.uima.runtime_2.2.2.incubating
    >                 Fragments=235
    > 235    RESOLVED
    > org.apache.uima.runtime.fragments.deployeditor_2.2.2.incubating
    >                 Master=234
    > For CDE (bundle#4), "org.apache.uima.util" package is imported from
    > Bundle#194
    >     org.apache.uima.util;
    > version="0.0.0"<update@../ws-test/org.apache.uima.runtimetoolkit.container/
    > [194]>
    > For UIMA runtime plugin "org.apache.uima.runtime" (Bundle#234), it has the
    > following resolution:
    >     org.apache.uima.jcas.tcas;
    > version="0.0.0"<update@../ws-test/org.apache.uima.runtimetoolkit.container/
    > [194]>
    >     org.apache.uima.util;
    > version="0.0.0"<update@../ws-test/org.apache.uima.runtimetoolkit.container/
    > [194]>
    > >From the above imported resolution, "org.apache.uima.util"  and "
    > org.apache.uima.jcas.tcas" come from the wrong plugin (Bundle#194) which
    > cause the problem for CDE to properly run.
    > It is a good idea to document this so that the tools that use UIMA plugin
    > will not create the wrong wiring as the above example.
    > Comment ?
    > - Tong

> Classes from uima-document-annotator.jar are not in Eclipse plugin
> ------------------------------------------------------------------
>                 Key: UIMA-1027
>                 URL: https://issues.apache.org/jira/browse/UIMA-1027
>             Project: UIMA
>          Issue Type: Bug
>          Components: Eclipse plugins
>    Affects Versions: 2.2.2AS, 2.2.2S
>            Reporter: Mikhail Sogrin
> Eclipse plugin org.apache.uima.runtime previously contained jars inside a plugin. Version
2.2.2 has jars unzipped. But contents of uima-document-annotator.jar were not added to 2.2.2
> I've previously submitted a report (UIMA-400) about the same jar which was not added
to 2.1.0 plugin by mistake, and it was fixed in 2.2.0, and now broken again in 2.2.2.
> In addition, there's a circular dependency for the package org.apache.uima.jcas.tcas,
i.e. the same package is exported and imported in manifest. Probably, it's caused by the same
missing classes from that jar.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message