I am new to UIMA Ruta. I try to run the Main.ruta in the ExampleProject came with Ruta 2.1.0 source release using Eclipse 3.7 according to the instruction. It seems the Ruta workbench picks up an incorrect descritor path. I tried to set new Arguments in the "Run Configurations". It doesn't work.
Due to some restriction at work, The UIMA Ruta plugins were installed manaully.
Please help. Thank you!
An error because of incorrect descriptor paths indicates that the plugin are correctly installed, but the descriptors themselves are not updated.
The descriptors use some absolute paths in their parameter configuration. Try to build the project twice in order to regenerate all descriptors, e.g, with Menu->Project->Clean. Then investigate the descriptor ExampleProject/descriptor/uima/ruta/example/MainEngine.xml and check if the absolute paths are correct (pointing to your workspace project), especially the parameter scriptPaths.
Thanks Peter. The problem truns out that Ruta workbench can't handle spaces in descriptor paths. I fixed the space problem and the rebuilt the project. Now it works.
Related
I am completely new to Ruta (and to Java).
I installed Eclipse, Maven plugin and Uima Ruta on my computer. I followed the instructions from the UIMA Ruta Guide and Reference. Eclipse shows I have got UIMA Runtime 2.10.2, UIMA Tools 2.10.2, UIMA Ruta Workbench 2.6.1 and UIMA-AS Deployment Descriptor Editor 2.10.3.
But now it turns out that I cannot write (well, compile/run) a single most simple program using Ruta because something is wrong with the imports.
When I write "PACKAGE uima.ruta.example", a red circle appears saying "The package declaration does not match the project structure" -- even if there is no other line in my program.
When I try to compile and run a simple program on an input file (right click on file > UIMA Ruta > Quick Ruta), nothing happens.
I suppose some important files simply haven't been downloaded onto my computer. When I am exploring the directory where I (think I) installed everything, I see there are loads of different "uima" amd "uimaj" packages in there, but I cannot find any packages called 'ruta' or 'ruta.example' or so.
What should I do? Where can I get the 'ruta' library? Does the 'ruta.example' library really exist or is it used in the book just as an example?
(Actually I would also be happy to receive an answer to the question "Why in God's name should I download an environment, install a plugin for it, install a subplugin for it, create a project for it and adjust its settings before writing some programs, instead of just installing and/or compiling some single stuff and just running my program with it in the command line?", but since such a way has not appeared yet officially (has it?), I suppose there should be some serious reasons for that.)
If you use a declaration like PACKAGE uima.ruta.example; it's also required that you put that file in the matching package (directory). So, if your Ruta file names MyExample.ruta it should be located in script/uima/ruta/example/MyExample.ruta. If the Ruta workbench is installed correctly, and you create a default UIMA Ruta project, then it's possible to execute the Ruta file via the file context menu. No additional resources have to be downloaded.
Don't forget to add example input files into the "input" directory. These will be processed and the result will be placed in the "output" directory.
If you are using the Ruta library in Maven project (In a custom project other then running it through the Ruta workbench of Eclipse) you have to add Ruta as dependency in the pom.xml. All transitive dependencies will be downloaded by the Maven system.
<dependency>
<groupId>org.apache.uima</groupId>
<artifactId>ruta-core</artifactId>
<version>2.6.1</version>
</dependency>
In our corpus we often find and need to parse data that is alpha-numeric as a single token (for example file hashes, email addresses, etc.) We have created our own ruta-core version by re-working the JFlex definition. Is there a way we can still work with this new version of ruta-core in Workbench?
If you use simple Ruta projects, you would need to replace the ruta.engine plugin with a different jar containing your ruta-core version. The clean way would be to build a complete update site with your version.
You could maybe also set your ruta-core jar in the classpath of your ruta launch configurations.
If you use maven-based projects, you can set the dependency to your version of ruta-core, which should then be used in the launch delegate.
For your use case, I would not use your own version of ruta-core at all. You could simply write your own version of the TokenLexer, as you probably did. Then, you can configure the utilized TokenLexer in the RutaEngine as there is a configuration parameter for setting it. Thus, there is already some functionality to customize the JFlex definition without building your own ruta-core.
DISCLAIMER: I am a developer of UIMA Ruta
I'm having trouble importing a typesystem into Ruta. I have two projects in my workspace:
UIMA project located ./workspace/UIMA_NLP/
Ruta project located at ./workspace/RUTA_CLARIFY/
I'm trying to load the Type System Definition file: ./workspace/UIMA_NLP/descriptors/type_system/nlpTypes.xml created in the UIMA project into the Ruta script.
I've been able to do this successfully if I copy the Type System Definition into the Ruta project into ./workspace/RUTA_CLARIFY/descriptor/nlpTypes.xml and loading it in the Ruta script with the following:
TYPESYSTEM nlpTypes;
However, when trying to import directly from the UIMA_NLP project I get 'error nlpTypes not found' in the editor. I've tried adding the fully qualified directory of the Type System Descriptor to the descriptorPaths field in the generated ruta engine without any success.
I've tried the following types system imports in script after adding the path to the descriptor paths:
TYPESYSTEM type_system.nlpTypes;
TYPESYSTEM descriptors.type_system.nlpTypes;
TYPESYSTEM UIMA_NLP.descriptors.type_system.nlpTypes;
What is strange is that I can add the nlpTypes.xml Type System Descriptor in the Type System generated by the Ruta script using the Imported Types and Import By Location and the types defined by the imported nlpTypes.xml appear in the Types. I can also type them in the editor when using auto-complete and the types appear. However, I will still get an error in the editor that 'Type "typename" is not defined in this script/block' even after using the auto-complete to complete the type name. Because of this I suspect I am not using the TYPESYSTEM import correctly for this case.
Am I using the TYPESYSTEM import incorrectly? Or is the only way to use my predefined Type System Descriptor to copy it to the Ruta project?
Adding the absolute path to the folder of the type system to the descriptiorPaths configuration parameter of your analysis engine descriptor should work. However, in which xml descriptor did you add it? If it is the generated descriptor of your script, then the modification will be overwritten by the workbench. You need to add the additional path to the template descriptor BasicEngine.xml of the project.
If the descriptorPath contains the paths to the descriptors folder of the other project, then the correct import would read: TYPESYSTEM type_system.nlpTypes;
Normally, you would reference the UIMA project from the Ruta project: Right-click on the Ruta project->Properties->Project References->Check the UIMA project
The default folders of referenced projects are automatically included in the descriptorPaths when the analysis engine descriptor is built by the workbench. In case of UIMA Pear projects, this would be the desc folder. For Java project this would be the output folder, e.g., bin or target/classes.
The strange error you report is really strange. Sounds like a problem of the project setup or descriptors that are not up-to-date. Try to clean the project: Menu->Project->Clean...
The error is maybe false positive due to the project setup. Can you launch the script and get results in the output folder?
I personally recommend using simple Ruta projects only for prototyping. For serious rule projects, especially if there are dependencies to other projects, I'd rather recommend a maven-built project. There is also an archetype for ruta projects in order to ease the setup.
DISCLAIMER: I am a developer of UIMA Ruta
I am currently trying to get my headless pde-build working but I am stuck on a point where I do not know how to continue.
The problem is how to define the related target platform to compile the plugins against.
I have a build.bat with the following call (all in one line!):
java -jar D:\target\eclipse\plugins\org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar
-application org.eclipse.ant.core.antRunner
-f D:\target\eclipse\plugins\org.eclipse.pde.build_3.5.2.R35x_20100114\scripts\productBuild\productBuild.xml
-Dbuilder=c:\pde-build\scripts %*
I tried to create the target eclipse platform from different parts: The eclipse SDK, RCP SDK, Delta Pack, PDE-SDK in all combinations but none of them worked well.
I got the following error:
BUILD FAILED
D:\target\eclipse\plugins\org.eclipse.pde.build_3.5.2.R35x_20100114\scripts\productBuild\productBuild.xml:18: Cannot fin
d ${eclipse.pdebuild.scripts}/build.xml imported from D:\target\eclipse\plugins\org.eclipse.pde.build_3.5.2.R35x_2010011
4\scripts\productBuild\productBuild.xml
where the variable ${eclipse.pdebuild.scripts} does not got resolved. I also tried to give this parameter via the command line but then I got another error regarding missing svn task which is absolutely confusing as this is working with my local eclipse installation referenced.
When I replace the path from d:/target/eclipse to my local eclipse installation the pde build works as expected!
This leads my to the point that the configuration of the target eclipse is not correct but in the moment I have no idea how to configure this!
My goal is the automate the pde build first on my local site without referencing my local eclipse and later on integrate this building process into our running cruisecontrol instance.
As I saw already another question about defining the target eclipse I would be happy if anyone can contribute hints or facts regarding the problem.
Regards,
Andreas
When performing a headless build, the target can be separate from the eclipse that is actually running the build itself. The problem you had here is that the eclipse that you were using to run the build did not have PDE/Build properly installed.
This is why the ${eclipse.pdebuild.scripts} was not set, because PDE/Build was not installed into that eclipse instance, the org.eclipse.pde.build bundle was not resolved and the code that sets this property never got called. Similarly, the necessary ant classpath entries for PDE/Build tasks would not have been set up properly either.
You need the Eclipse with PDE installed inside to run the build, but the target for the build can be separate from this.
In the build.properties file found under -Dbuilder=c:\pde-build\scripts you can set several properties:
baseLocation This is a path to an eclipse that is your target.
buildDirectory This is where the build will actually take place, source is fetched to plugins/ and features/ subfolders, but if there are already binary plugins located here then those become part of the target as well.
pluginPath This is a list of paths (separated with ';' on windows or ':' on linux) containing other locations that should be considered as part of your target. These locations can be several things:
The root of an eclipse-like install with plugins/ and features/ subfolders. This is a good way to provide the delta-pack instead of just unzipping it on top of an eclipse install.
The root of a workspace-like folder, where all subfolders are treated as plugins or features depending on the presence of a manifest or feature.xml.
The root of a bundle or feature, or the jar for a bundle.
If you are doing a p2 build (p2.gathering = true) you can also provide p2 repositories under a ${repoBaseLocation} which will be transformed and placed under ${transformedRepoLocation} and will become part of your target, and the p2 metadata there will get reused during the build.
after some more time of investigation I found out, what I did wrong so far. As I mentioned above defining the target platform is not that easy as copying the SDK and plugins in into one location (as it was in early times of eclipse dev).
The working solution by now is the following: Copying the eclipse SDK into the target location and run this version. Install inside this the neccessary PDE-Tools to enable plugin development. After that, close the IDE and copy the delta pack + the respective svn plugin (I used org.eclipse.pde.build.svn-1.0.1RC2 from sourceforge) into the target platform and you're done.
Now my automated PDE build is running as expected.
Only minor issue now is the following: The result product contains eclipse-specific menu entries which are not there when I ran this from inside my dev-eclipse.
Any hints on that?
I just posted an answer to my question on this kind of topics, may be this can help you:
Plugin product VS Feature product
I downloaded the source code for the EMF based UML2 Plugin and changed a class in the org.eclipse.uml2.uml.edit project to remove special characters when returning string representations. Now when I export the projects and place the jar files either in the dropins directory or replace my current uml2 plugin jar files in plugins directory, The UML files are no longer recognized, in short my modified plugin does not install correctly (no error is thrown and I can see the files being picked up under Plugins->Target Platform) .
However, When I run the plugin as an eclipse application (from the workspace) I can see the changes I made being reflected in the new instance of eclipse.
What can I do to ensure that the plugin installs correctly?
Is there a documented procedure of how to build the uml2 plugin (or any comparable plugin) after modification?
Select the project and open the context menu. There is an entry PDE near the bottom of the menu. In there, you can find an entry to build the plugin for deployment. This gives you the features and plugins directory with the fixed files. Copy both into your Eclipse install.
Unless the UML2 plugins require some kind of magic build script, exporting the one plugin you changed and overwriting the original in your Eclipse installation should be the easiest solution. One potential problem which comes to mind is conflicting plugin version numbers: make sure you don't have two identical versions of your modified plugin in your Eclipse installation.
When debugging plugins which apparently don't work properly at runtime, I always look at Help > About Eclipse Platform > Configuration Details. This lists all the plugins found by Equinox during startup, along with their status (see the Javadoc of the org.osgi.framework.Bundle interface for explanation).
I faced the exact same problem as you describe here . I dont have any answer to your problem but i am sharing what worked for me .
I created a local update site of the plugin on my system. Create update site for your plug-in article explains very very nicely the steps needed to accomplish this .