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
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>
I've created an feature-based Eclipse product where all dependencies respectively external plugins are specified in a dependencies feature project. Some dependencies need different versions of the same plugin. How can I specify several versions of a plugin in a feature.xml? Eclipse seems to always use the current version of a plugin. I've tried to add a dependency with a strict version interval, e.g. [1.6.0.v201011041432,1.6.0.v201011041432], in the feature.xml but Eclipse doesn't accept this format.
I had a similar problem when running a feature based product within Eclipse (Kepler) where multiple versions of the same bundle were involved.
In the end I used a workaround - I changed the symbolic names of the bundles, so they all have different names. If you consequently use Import-Package instead of Require-Bundle this will make no difference in the dependencies you define for bundles or in the OSGi runtime, only in your Feature definition.
This solution is not pretty, but at least it's rather easy to do.
Thinking about that OSGi is intended to target exactly this kind of use case where you have multiple versions of the same dependency/bundle it's rather strange how bad the support in Eclipse is, if you actually have this kind of use case.
I have a Scala Play project and currently I show the current application version at some location in my main template. The version I can easily define in the conf/messages file. However, since I have an automated build for creating releases, the release iterations will update the build.sbt increasing the version according to the release there e.g. version := "1.0.6-SNAPSHOT"
I could use the same mechanics during the release to update my conf/messages file as well but instead I would prefer to have my conf/messages file including the version information from build.sbt e.g. alla application.version=${sbt.application.version}.
How can I accomplish this? is it possible at all?
UPDATE: it is worth mentioning that in Maven these build settings become Java system properties and can be easily used.
You can use sbt-buildinfo plugin to generate a Scala source based on the build.sbt.
The plugin generates a BuildInfo object, which contains information you can then use to display the application version.
Otherwise I don't think you can access sbt information from your configuration.
You can use the xsbt-filter plugin to achieve this. It basically works like Maven's resource filtering mechanism, and exposes the project's name, version, etc. by default. You can further configure it to expose other properties.
Greetings,
I have a java project which I export as a jar. This java project also uses JNI.
So far, the only method I could find to use this jar in an Eclipse plugin is to wrap it in an other eclipse plugin project, and add this jar wrapper plugin to dependencies of my actual plugin.
I've wrestled with Eclipse's paths and dependency settings for days, and this method is the only one that works for me at the moment.
However, it is not very practical, since when I change my JNI based java code, I can simply create a new jar, but to connect that jar to my actual plugin, I have to re-create the jar wrapper plugin every time.
That is, I delete the jar wrapper plugin project, with everything on the disk, and re create it with the same name, pointing to the updated jar. I also have to drop the reference to this project from the actual plugin project and add again (maybe this has gotten smarter recently, but I did not test it)
This is time consuming, and I can't add this wrapper plugin project to svn either, since it is being created from scratch every time.
If I could simply update a jar wrapping eclipse plugin project by pointing at the new version of jar, that would solve my problem, and I could commit the project to svn after each update.
Is there any method you can think of which may help me run this process smoothly?
Best Regards
Seref
An Equinox-only (i.e. non-standard OSGi) method of using external libraries in an OSGi bundle without physically wrapping them is bundling by reference: you still need a wrapper plugin, but it does not contain the wrapped library itself but a reference in the bundle manifest's Bundle-Classpath header with a syntax like this:
Bundle-Classpath: external:/path/to/your/lib.jar
During development time, this is quite convenient and saves the effort of having to recreate the wrapper plugin whenever the wrapped library is updated. During deployment time, you'll either have to install the library along with the product or use a traditional wrapper plugin (one containing the actual library). You can also use the same wrapper plugin for bith use cases, but change the Bundle-Classpath from external:/stuff/lib.jar to libs/lib.jar dependent on whether you want to use the wrapped or the external library.
(Most of this comes from the book OSGi and Equinox - Creating Highly Modular Java Systems, which I don't really like, but which nevertheless contains useful stuff about Equinox (Eclipse's OSGi implementation) and the PDE build system.)
I have a serious probleam with my Eclipse Plugin..
My plugin depends on another two plugins. All of theese plugins (including my plugin) use Mozilla Rhino engine - two of them use js.jar (version 1.4). But my plugin uses new version, which is not released yet and is packed in MyRhino.jar.
While developing, everything goes fine - code completion offers me classes and methods from my special version of rhino, no errors etc.
But when I run my plugin, a different version of Rhino is used and I get runtime exceptions like ClassNotFoundException and so on.
How am I supposed to tell eclipse to use the same jar in runtime as in development time?
When I was developing plugins on NetBeans, the solution was simple - wrapping the jar in a separate module, set which packages to export and declare dependency on this new module..
I found simmilar solution in Eclipse, however it did not work for me - although I declared a dependency on the wrapper plugin, the packages and classes were not available even in development time.
I've spent hours with this probleam and not solved it, so and help is appreciated. Thanks everyone.
Make sure your dependencies are correct. If your code depends on new version of library, then you need to indicate that in your MANIFEST.MF. E.g. if you require bundle org.mozilla.rhino, specify minimum version you need:
Require-Bundle: org.mozilla.rhino;bundle-version="1.5.0"
Your MyRhino.jar will need to specify correct version (e.g. 1.5.0), even though it is not released yet:
Bundle-Version: 1.5.0.qualifier
(If MyRhino.jar isn't converted to plugin yet, you need to do that manually: you can simply craete new plugin project using existing JAR in Eclipse)
Alternativaly, you can wrap MyRhino.jar into your plugin, and remove dependencies on other plugins. To do this, use Bundle-ClassPath (see http://www.aqute.biz/Blog/2007-02-19 for details). If you put your MyRhino.jar directly into your plugin, then Bundle-ClassPath should be:
Bundle-ClassPath: .,MyRhino.jar
Finally I've solved it..
It's simple to create the wrapper plugin form existing jar by the new project wizard in eclipse.. But the catch is that the wizard does not include the jar in bundle classpath (as I expected). Prety confusing (at least for me) that the wizard does only half of the job for you :/
After inserting the jar in the wrapper plugin bundle classpath, everytning works.
Thanks Peter for your answear anyway :)