[ 
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

 -Tong
------------------------------ 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 <[EMAIL PROTECTED]> 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?

    -Marshall

    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"<[EMAIL 
PROTECTED]/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"<[EMAIL 
PROTECTED]/ws-test/org.apache.uima.runtimetoolkit.container/
    > [194]>
    >     org.apache.uima.util;
    > version="0.0.0"<[EMAIL 
PROTECTED]/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 plugin.
> 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.

Reply via email to