|
[
Permlink
| « Hide
]
Marshall Schor added a comment - 14/Apr/09 11:42 AM
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.
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 ? 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 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 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 ? 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) I have Eclipse 3.3.2 and an updated EMF 2.3.2.v200802051830 Worked for me on the command line, then used mvn eclipse:eclipse to set up the project.
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: On the last line I get a type safety warning in eclipse. I think that means Can we close this issue, or is there remaining work that needs to be done?
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. 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.
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 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)
I committed your patches, do you still want the ecore code moved to ecore_src ?
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, Ooops – we need to move the same files in the uima-as build.
FWIW I've tested jcasgen in the uima-as build Can we close the issue now or does the jcas stuff needs more testing ?
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.
This issue still needs testing, everything else is done.
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.
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? This current approach has the following issues:
A simpler approach would be to
This would allow stand-alone running of the ecore examples without Eclipse being installed or available. The Jars in question are
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? 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.
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.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Closed
Major
Remove EMF dependency from uimaj-ep-runtime plugin
