UIMA
  1. UIMA
  2. UIMA-1326

Remove EMF dependency from uimaj-ep-runtime plugin

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.3
    • Fix Version/s: 2.3
    • Component/s: Eclipse plugins
    • Labels:
      None

      Description

      The uimaj-ep-runtime plugin depends on EMF, this dependency makes deploying in
      an non eclipse OSGI environment difficult since EMF depends on org.eclipse.core.runtime,
      which depends on many other eclipse plugins.

      Since EMF is only really used in the examples project, the dependency is removed
      from uimaj-core and the classes Ecore2UimaTypeSystem and UimaTypeSystem2Ecore.java
      are moved to uimaj-examples.

      The uimaj-ep-runtime plugin contains currently uimaj-examples, that
      could be moved to a seperate plugin or shipped with an OSGI bundle.

      1. uimaj-distr_1326.patch
        1 kB
        Burn Lewis
      2. uimaj-examples_1326.patch
        0.8 kB
        Burn Lewis
      3. uima-as-distr_1326.patch
        2 kB
        Burn Lewis

        Activity

        Hide
        Marshall Schor added a comment -

        I'm closing this issue for the 2.3 release. We can open another issue if we want more changes here around how the ecore things are packaged.

        Show
        Marshall Schor added a comment - I'm closing this issue for the 2.3 release. We can open another issue if we want more changes here around how the ecore things are packaged.
        Hide
        Thilo Goetz added a comment -

        We provide a lot of code where users first have to download something else before they can make it work. I'd vote for not including the ecore jars.

        Show
        Thilo Goetz added a comment - We provide a lot of code where users first have to download something else before they can make it work. I'd vote for not including the ecore jars.
        Hide
        Marshall Schor added a comment -

        This current approach has the following issues:

        • it essentially requires Eclipse. I think our intent with ecore did not include making it Eclipse - specific
        • It has special treatment to isolate source files outside of the normal source path, and special readme's to have the user include these in the source path, after they add ecore support jars from Eclipse, which they would have to obtain somehow.

        A simpler approach would be to

        • have no special treatment for the ecore examples
        • ship (distribute) the needed ecore jars with the examples, in a /lib directory

        This would allow stand-alone running of the ecore examples without Eclipse being installed or available.

        The Jars in question are

        • org/eclipse/emf/common-2.1.0.jar (134KB)
        • org/eclipse/emf/ecore-2.1.0.jar (625 KB)
        • org/eclipse/emf/ecore-xmi-2.1.0.jar (142KB)

        These we can distribute in binary form only under "category b" license terms - we have to include things in the NOTICE/LICENSE files for this.

        (Note that the maven build already gets these Jars from the maven repos and mvn eclipse:eclipse on the uimaj-examples project puts these jars into the generated classpath.)

        Should we change things to this simpler approach but which requires us to ship the 3 ecore support Jars, or leave things the way they are?

        I'm on the fence... in favor of simplicity, but not wanting to grow our bin distribution by 900KB. Other opinions?

        Show
        Marshall Schor added a comment - This current approach has the following issues: it essentially requires Eclipse. I think our intent with ecore did not include making it Eclipse - specific It has special treatment to isolate source files outside of the normal source path, and special readme's to have the user include these in the source path, after they add ecore support jars from Eclipse, which they would have to obtain somehow. A simpler approach would be to have no special treatment for the ecore examples ship (distribute) the needed ecore jars with the examples, in a /lib directory This would allow stand-alone running of the ecore examples without Eclipse being installed or available. The Jars in question are org/eclipse/emf/common-2.1.0.jar (134KB) org/eclipse/emf/ecore-2.1.0.jar (625 KB) org/eclipse/emf/ecore-xmi-2.1.0.jar (142KB) These we can distribute in binary form only under "category b" license terms - we have to include things in the NOTICE/LICENSE files for this. (Note that the maven build already gets these Jars from the maven repos and mvn eclipse:eclipse on the uimaj-examples project puts these jars into the generated classpath.) Should we change things to this simpler approach but which requires us to ship the 3 ecore support Jars, or leave things the way they are? I'm on the fence... in favor of simplicity, but not wanting to grow our bin distribution by 900KB. Other opinions?
        Hide
        Marshall Schor added a comment -

        This approach puts files from uimaj-examples in SVN and our source distribution into two separate files in the binary distribution. I think it would be better to keep everything in sync, and split the SVN and source distributions the same way, and not have a special split step in the assembly, because it would be clearer and more maintainable in the future (my beliefs ) Other opinions?

        Show
        Marshall Schor added a comment - This approach puts files from uimaj-examples in SVN and our source distribution into two separate files in the binary distribution. I think it would be better to keep everything in sync, and split the SVN and source distributions the same way, and not have a special split step in the assembly, because it would be clearer and more maintainable in the future (my beliefs ) Other opinions?
        Hide
        Thilo Goetz added a comment -

        I think it's been tested as much as we can for now, everything seems to be fine. Once we have a release candidate, we'll do more testing. I suggest we close the issue.

        Show
        Thilo Goetz added a comment - I think it's been tested as much as we can for now, everything seems to be fine. Once we have a release candidate, we'll do more testing. I suggest we close the issue.
        Hide
        Joern Kottmann added a comment -

        This issue still needs testing, everything else is done.

        Show
        Joern Kottmann added a comment - This issue still needs testing, everything else is done.
        Hide
        Thilo Goetz added a comment -

        I tested JCasGen from the CDE, still works fine. However, I tested from an eclipse workspace. Since I'm unable to build the eclipse update site in a way that it actually works, I can't test properly. I.e., can't test if the dependency is resolved properly when our tools are installed into a clean eclipse.

        Show
        Thilo Goetz added a comment - I tested JCasGen from the CDE, still works fine. However, I tested from an eclipse workspace. Since I'm unable to build the eclipse update site in a way that it actually works, I can't test properly. I.e., can't test if the dependency is resolved properly when our tools are installed into a clean eclipse.
        Hide
        Joern Kottmann added a comment -

        Can we close the issue now or does the jcas stuff needs more testing ?

        Show
        Joern Kottmann added a comment - Can we close the issue now or does the jcas stuff needs more testing ?
        Hide
        Burn Lewis added a comment -

        Ooops – we need to move the same files in the uima-as build.

        FWIW I've tested jcasgen in the uima-as build

        Show
        Burn Lewis added a comment - Ooops – we need to move the same files in the uima-as build. FWIW I've tested jcasgen in the uima-as build
        Hide
        Burn Lewis added a comment -

        That's what the patch to bin.xml does ... all are under src in svn but when we build the binary distribution we now move 3 files (was 1) to ecore_src.

        All looks fine now - thanks,
        Burn.

        Show
        Burn Lewis added a comment - That's what the patch to bin.xml does ... all are under src in svn but when we build the binary distribution we now move 3 files (was 1) to ecore_src. All looks fine now - thanks, Burn.
        Hide
        Joern Kottmann added a comment -

        I committed your patches, do you still want the ecore code moved to ecore_src ?

        Show
        Joern Kottmann added a comment - I committed your patches, do you still want the ecore code moved to ecore_src ?
        Hide
        Burn Lewis added a comment -

        One patch fixes the compile error exposed by new versions of EMF, the other puts 2 more emf-dependent routines in the ecore_src directory (I think I have the syntax correct ... the build now produces a project that compiles)

        Show
        Burn Lewis added a comment - One patch fixes the compile error exposed by new versions of EMF, the other puts 2 more emf-dependent routines in the ecore_src directory (I think I have the syntax correct ... the build now produces a project that compiles)
        Hide
        Burn Lewis added a comment -

        If I add to the uimaj-examples classpath the ecore jars that maven puts in my repository when building from svn (e.g. org/eclipse/emf/ecore/2.1.0/ecore-2.1.0.jar) the build works. When I instead use the ones in my eclipse/plugins directory (e.g. org.eclipse.emf.ecore_2.3.2.v200802051830.jar) that match my Eclipse 3.3.2, the compile of UimaTypeSystem2Ecore fails at line 188: eclass.getESuperTypes().add(superclass);

        But I don't think we intended to have any ecore code in this project as we have some of it in ecore_src ... so the simplest fix is to move the ecore-dependent files into examples/ecore_src instead of examples/src

        Show
        Burn Lewis added a comment - If I add to the uimaj-examples classpath the ecore jars that maven puts in my repository when building from svn (e.g. org/eclipse/emf/ecore/2.1.0/ecore-2.1.0.jar) the build works. When I instead use the ones in my eclipse/plugins directory (e.g. org.eclipse.emf.ecore_2.3.2.v200802051830.jar) that match my Eclipse 3.3.2, the compile of UimaTypeSystem2Ecore fails at line 188: eclass.getESuperTypes().add(superclass); But I don't think we intended to have any ecore code in this project as we have some of it in ecore_src ... so the simplest fix is to move the ecore-dependent files into examples/ecore_src instead of examples/src
        Hide
        Burn Lewis added a comment -

        Sorry, I should have clarified my problem. The build worked fine but the problem came when I took the resultant zip file (binary) and installed it and tried to build the examples project as our docs recommend. Presumably we don't require maven for that step.

        Show
        Burn Lewis added a comment - Sorry, I should have clarified my problem. The build worked fine but the problem came when I took the resultant zip file (binary) and installed it and tried to build the examples project as our docs recommend. Presumably we don't require maven for that step.
        Hide
        Joern Kottmann added a comment -

        I did all changes, but Marshall said it should be tested if the uimaj-ep-jcasgen still works, which is used in two places Component Descriptor Editor in Eclipse and jcasgen_merge script.

        Though despite Marshalls worries I do not think that the change affects uimaj-ep-jcasgen.

        Show
        Joern Kottmann added a comment - I did all changes, but Marshall said it should be tested if the uimaj-ep-jcasgen still works, which is used in two places Component Descriptor Editor in Eclipse and jcasgen_merge script. Though despite Marshalls worries I do not think that the change affects uimaj-ep-jcasgen.
        Hide
        Thilo Goetz added a comment -

        Can we close this issue, or is there remaining work that needs to be done?

        Show
        Thilo Goetz added a comment - Can we close this issue, or is there remaining work that needs to be done?
        Hide
        Joern Kottmann added a comment -

        Also works for me on the command line and in eclipse, used mvn eclipse:eclipse to set up the project.

        A short look at the code:
        EClass eclass = (EClass) eclassifier;
        // set supertype
        String supertypeName = type.getSupertypeName();
        EClassifier superclass = lookupEClassifierForType(supertypeName); // creates EClass if not
        // already existing
        eclass.getESuperTypes().add(superclass); // line 188

        On the last line I get a type safety warning in eclipse. I think that means
        that we are using an older version of ecore (2.10).

        Show
        Joern Kottmann added a comment - Also works for me on the command line and in eclipse, used mvn eclipse:eclipse to set up the project. A short look at the code: EClass eclass = (EClass) eclassifier; // set supertype String supertypeName = type.getSupertypeName(); EClassifier superclass = lookupEClassifierForType(supertypeName); // creates EClass if not // already existing eclass.getESuperTypes().add(superclass); // line 188 On the last line I get a type safety warning in eclipse. I think that means that we are using an older version of ecore (2.10).
        Hide
        Thilo Goetz added a comment -

        Worked for me on the command line, then used mvn eclipse:eclipse to set up the project.

        Show
        Thilo Goetz added a comment - Worked for me on the command line, then used mvn eclipse:eclipse to set up the project.
        Hide
        Burn Lewis added a comment -

        I'm probably missing something but I can't build the uimaj-examples project now. I built a new uima core uimaj-2.3.0-incubating-SNAPSHOT-bin.zip and installed it, then created a new workspace and imported the uimaj-examples project. It failed on the new ecore classes in org.apache.uima.examples.xmi so I followed the instructions in the ecore_src directory to add the 3 emf jar files to my classpath and now I have only one error:

        The method add(EClass) in the type List<EClass> is not applicable for the arguments (EClassifier)
        uimaj-examples/src/org/apache/uima/examples/xmi UimaTypeSystem2Ecore.java line 188

        I have Eclipse 3.3.2 and an updated EMF 2.3.2.v200802051830

        Show
        Burn Lewis added a comment - I'm probably missing something but I can't build the uimaj-examples project now. I built a new uima core uimaj-2.3.0-incubating-SNAPSHOT-bin.zip and installed it, then created a new workspace and imported the uimaj-examples project. It failed on the new ecore classes in org.apache.uima.examples.xmi so I followed the instructions in the ecore_src directory to add the 3 emf jar files to my classpath and now I have only one error: The method add(EClass) in the type List<EClass> is not applicable for the arguments (EClassifier) uimaj-examples/src/org/apache/uima/examples/xmi UimaTypeSystem2Ecore.java line 188 I have Eclipse 3.3.2 and an updated EMF 2.3.2.v200802051830
        Hide
        Joern Kottmann added a comment -

        I now removed the EMF dependency from the uimaj-ep-runtime plugin. To achieve that I removed the EMF dependency from uimaj-core and moved the ecore classes to the uimaj-examples project, since thats the only place where they are used. To finally get rid of the EMF dependency in the uimaj-ep-runtime plugin I removed the uimaj-examples from it.

        Do we need the uimaj-examples in an OSGI environment ?
        If so we could just add a OSGI manifest to the uimaj-examples jar file or create a separate project which wraps it
        in the uimaj-ep-runtime plugin style.

        Show
        Joern Kottmann added a comment - I now removed the EMF dependency from the uimaj-ep-runtime plugin. To achieve that I removed the EMF dependency from uimaj-core and moved the ecore classes to the uimaj-examples project, since thats the only place where they are used. To finally get rid of the EMF dependency in the uimaj-ep-runtime plugin I removed the uimaj-examples from it. Do we need the uimaj-examples in an OSGI environment ? If so we could just add a OSGI manifest to the uimaj-examples jar file or create a separate project which wraps it in the uimaj-ep-runtime plugin style.
        Hide
        Marshall Schor added a comment -

        I mis-remembered how this got set up. (It's older code that dates from Eclipse ~2.1 vintage).

        JCasGen has a mode where it can "merge" the generated code with previous extensions that a user might have written, in a way the preserves those. It uses the code generation facilities of EMF to do this. See http://incubator.apache.org/uima/downloads/releaseDocs/2.2.2-incubating/docs/html/tools/tools.html#ugr.tools.jcasgen (the section starting "There are several versions of JCasGen").

        This was set up by moving the dependency on EMF code generation into a plugin, uimaj-ep-jcasgen. That plugin's POM does have a dependency on EMF. The plugin is used in two cases: 1) from the Component Descriptor Editor in Eclipse, and when running the tool script jcasgen_merge.bat or .sh; In the latter case the "application" calls the class JgPluginRunner (see the plugin.xml file for that plugin).

        The Component Descriptor Editor has a dependency on uimaj-ep-jcasgen, which in turn depends on EMF codegen.

        I think this will continue to work, if you remove the EMF dependency from the core, but let's test to be sure .

        Show
        Marshall Schor added a comment - I mis-remembered how this got set up. (It's older code that dates from Eclipse ~2.1 vintage). JCasGen has a mode where it can "merge" the generated code with previous extensions that a user might have written, in a way the preserves those. It uses the code generation facilities of EMF to do this. See http://incubator.apache.org/uima/downloads/releaseDocs/2.2.2-incubating/docs/html/tools/tools.html#ugr.tools.jcasgen (the section starting "There are several versions of JCasGen"). This was set up by moving the dependency on EMF code generation into a plugin, uimaj-ep-jcasgen. That plugin's POM does have a dependency on EMF. The plugin is used in two cases: 1) from the Component Descriptor Editor in Eclipse, and when running the tool script jcasgen_merge.bat or .sh; In the latter case the "application" calls the class JgPluginRunner (see the plugin.xml file for that plugin). The Component Descriptor Editor has a dependency on uimaj-ep-jcasgen, which in turn depends on EMF codegen. I think this will continue to work, if you remove the EMF dependency from the core, but let's test to be sure .
        Hide
        Joern Kottmann added a comment -

        I checked the uimaj-tools pom and it does not depend on EMF and uimaj-ep-runtime does not contain
        the Component Descriptor Editor, or did I missed something ?

        Show
        Joern Kottmann added a comment - I checked the uimaj-tools pom and it does not depend on EMF and uimaj-ep-runtime does not contain the Component Descriptor Editor, or did I missed something ?
        Hide
        Marshall Schor added a comment -

        EMF parts are used also in the uimaj-tools part for the JCas generation tool -(not part of the uimaj-core). It might already be a dependency of the Component Descriptor Editor.

        Show
        Marshall Schor added a comment - EMF parts are used also in the uimaj-tools part for the JCas generation tool -(not part of the uimaj-core). It might already be a dependency of the Component Descriptor Editor.

          People

          • Assignee:
            Joern Kottmann
            Reporter:
            Joern Kottmann
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development