I have studied the default UIMA Ruta Workbench Eclipse project enough to significantly understand its moving parts - for instance, why the input/ and output/ folders behave as they do, how to accomplish the project using the jcasgen and other Maven plugins, etc.
But even after hours of studying the project and playing with Maven to try to get it to work, I still have a lot of trouble doing something very simple: using the DKPro libraries (the types especially) from a Ruta script.
My fundamental question is this: what is the path of least resistence towards using the types and analysis components from the DKPro and TC libraries within a Ruta script?
My specific questions are:
I noticed that in the desc/type folder of many api jars there are TypeSystemDescription XML files that would appear to be appropriate for use with Ruta. Is there some way of getting a "master" TypeSystemDescription XML file for the DKPro components?
Is there a project of significant complexity that uses both Ruta and DKPro that I can study?
What is the distinction between an AnalysisEngine as in what you do with Ruta scripts and an Analysis Component you write in Java?
Edited to reflect less frustration
Actually, the Ruta and DKPro people do workshops together and sit happily around the campfire afterwards - or at least in a cocktail bar and have some drinks. Unfortunately, we don't get around to doing that very often.
The kind and number of questions you are asking calls for a tutorial ;)
Did you have a look the slides and examples from our joint workshop at GSCL 2013?
It includes several examples of how to use DKPro Core and Ruta together. In those examples, there is a Maven project responsible for fetching the DKPro Core dependencies and separate Ruta projects then have a dependency on that Maven project and use the analysis engines.
It should also work to have a single project with both, the Ruta and Maven natures.
The way to get a single type descriptor for all DKPro Core types in your classpath (or rather for all uimaFIT-enabled types in your classpath) is
import org.apache.uima.fit.factory.TypeSystemDescriptionFactory;
OutputStream os = ...
TypeSystemDescriptionFactory.createTypeSystemDescription().toXML(os);
Check out the GSCL 2013 tutorial examples.
AnalysisComponent represents the view from the inside, i.e. from the perspective of the developer of components (the view from within the framework). AnalysisEngine represents the view from the outside, i.e. from the user of a component/workflow. However, typically one would say "I'm implementing a new analysis engine" and mean "I'm going to subclass JCasAnnotator_ImplBase (an implementation of AnalysisComponent)". See also this post on the UIMA developer mailing list.
Disclosure: I am a DKPro Core developer and an Apache UIMA developer.
Related
I have been working with Eclipse RCP for over a week now, and I've now been given an Eclipse plugin written in 3.x, which I need to migrate to 4.x. I'm using a book called Eclipse 4 RCP by Lars Vogel which has a small section on this, but I can't for the life of me figure out what I'm to do.
I'm trying to do this throught the use of the compatiblity layer. It mentions to add a couple of features for this (org.eclipse.rcp, org.eclipse.emf.ecore, org.eclipse.emf.common) and your ready to go, but I don't exactly know what I'm to do here. Like do I add these to the existing product file of the 3.x plugin I've been given, or do I create a separate e4 project and point to that. Many of the tutorials I read are a bit vague with the details and its a shame there's no proper step by step guide for beginners with this. Any help would be great.
Probably, you should be creating a separate e4 plug-in project for this. And where you have to configure your extensions/extension points in e4 ways.
Basically, like creating a new project.
If you want to migrate your Eclipse 3.x RCP application to the Eclipse 4 programming model, you can't directly reuse existing plugin.xml based user interface components, e.g. Views or Editors based on the definition in plugin.xml .
Components based on the plugin.xml file must be adjusted to avoid inheritance of Eclipse classes and to use the programming model based on #Inject . They also must be contributed to the application model.
Components which are not directly based on the plugin.xml file must be adjusted if they use Eclipse 3.x singletons, as for example Platform or PlatformUI , to access Eclipse API
you may want to take a look at this page: https://www.eclipse.org/community/eclipse_newsletter/2013/february/article3.php
this might be a duplicate question (see Xtext Project: Add Jar Libraries with the Project Wizard Manager into the Classpath/Referenced Libaries of the clients Project), but I'm not able to comment on the original one due to low reputation.
Therefore my question regarding a similar topic:
I created a custom DSL which is working nice so far. The next step for us is to support newly created projects in this language with a custom library that will come as a dependency for created projects. This library was also created using our DSL so it's fully compatible with other projects.
This library will contain basic datatypes and other types as well as the generated code that will be used by the generator of the "surrounding" project.
I would need a hint on how to include this jar-file into the process of new-project-instantiation. Adding it manually to the created project works like a charm, but I'd like to have some automatism in this.
I'm on to creating a custom project wizard for the DSL, but I'm kind of stuck there due to the not-so-availability of in-depth documentation on this topic.
Thanks
noff
I think (see below) that I would like to structure a Clojure project as multiple modules, with ordered dependencies - just like Maven lets me do with multi-modules projects.
But I can't see how to do this with Leiningen - all I can see is the checkouts fix described in the FAQ which doesn't seem to be as powerful.
Will lein do this? Should I be using Gradle instead? Or is this kind of thing not needed?
Some more context: I am wondering how to architect a modular application that supports plugins (which I imagine means jars dumped on the classpath). And am wondering to what extent I can structure that as a core + plugins (I am thinking I should be able to do something with Clojure's dynamic code loading and not have to go with Java/OSGi). So I guess the driving motivation for a single project comes from wanting some way of packaging everything (the core + default plugins) as a single blob that is easy for the end user, but which can also be divided up (and which is built and tested in fragments, testing the logical independence of each module). More general advice about this is welcome
Update
A possible solution that wasn't mentioned below is using a Maven plugin - I assume that supports everything Maven does, but compiles Clojure, so will work with nested modules, etc.
First, it does not seem like Leiningen supports a module hierarchy like Maven does. The checkouts are the next closest thing it has. It should be sufficient though to develop a modular application in Clojure though.
For the project structure, I would have an API project, a "core" project, the plugins themselves, and a separate packaging project. The core and the plugins should only depend on the API. Which build tool you use to create the packaging project is up to you. Gradle would probably be more effective at handling the packaging, however having the "checkout" functionality Leiningen offers could make development of the system as a whole easier.
I would take a look at the code for Leiningen and Noir to figure out how to effectively handle this.
For dynamically loading the plugins, I would start with looking how Noir handles it in two of their files:
server.clj has namespace loading for all files under a particular namespace. Under the hood it uses tools.namespace, but you can easily see how it's used to require every namespace under a particular base. This is how Leiningen handles custom tasks as well - the base definition for the task should be in the leiningen.$task namespace.
core.clj has what I would use for plugin registration. In summary, use a map under an atom and add plugins to that map. I would advice wrapping the registration with a macro to keep your code cleaner.
What I listed above should be sufficient if you don't need to handle adding plugins at run time. If you don't have every plugin on the classpath during start-up, I would recommend utilizing pomegranite to add entries to the classpath. You can see an example in classpath.clj.
This is a relatively open ended question so I wouldn't just mind being pointed in the right direction.
I have a product that uses the Eclipse workbench to allow users to program in a custom language. For this product, I will also have some minor UI and internal changes for a lighter version to be exported. For example, a full version of the product contains some extra views and menus, and behaves slightly differently (like when creating a new file) where as the ligher version does not contain a lot of view and has a couple of different more simplified ones.
I do not want to make a copy of my workspace and then have 2 separate workspaces for a full version and a lighter version as that will be difficult to maintain in the long run especially when there are changes in code relevant to both. I want to be able to export both, full and light versions of a product from a common workspace.
How can I go about this? Or where can I start looking?
The product is a collection of features and uses the Eclipse workbench as its base application.
I would like to clarify that I am asking how I could hide a view for the full or light version, as an example. I know in C#, we have options like #if. I have seen a lot of questions which refer to having 2 different versions of the same code, but nothing about how they could have 2 different versions of the same code.
You want the Eclipse RCP book it really fully explains how to do this. And to do it you need a solid understanding of the concepts of Eclipse plugin, feature, product, fragment and a few other things.
Essentially you can segment your application in to multiple plugins (have a base plugin for example, and then another that provides additional functionality). Then you organize those plugins into features that are the collection of the functionality to be installed. The notion of a "product" in Eclipse has to do with the branding, so you would probably have two products, a lite and a full one. The products could have a branding plugin (where the product is actually declared).
This should get you started.
Background
I'm a developer of the Vrapper project.
Vrapper contains of 2 major parts
Vim-emulation library (vrapper.core)
Eclipse part that makes a good use of it
We want vrapper.core to be Eclipse-unaware, so it's reusable
outside of the Eclipse. Currently, we can "vrap" all sorts of Eclipse
text editors and our little mock text editor that we use for unit testing.
vrapper.core implements all sorts of Vim commands, modes, etc.
Those all communicate with Platform - an interface that abstracts out
underlying stuff (text editor, clipboards, settings system, etc.).
When mode is created for an editor it asks platform if there are extra
commands that are approperiate for underlying editor, currently edited file type, etc.
EclipsePlatform provides those commands using Eclipse extension points mechanism.
So, let's consider the following projects (there are more):
vrapper.core - Eclipse-independent code for Vrapper
vrapper.eclipse - Eclipse plug-in that depends on vrapper.core
surround.core - Eclipse-independent code that emulates surround.vim (Vim plug-in)
surround.eclipse - Eclipse fragment for vrapper.eclipse
that makes it provide commands form surround.core.
There are two ways we can deal with those:
One plug-in to rule them all
This is how it should look like from Eclipse's perspective.
There is one plug-in that contains code from vrapper.eclipse and vrapper.core,
and one fragment that contains code from surround.core and surround.eclipse.
Many plug-ins
There are 3 plug-ins
two OSGified libraries vrapper.core, surround.core
vrapper.eclipse
surround.eclipse fragment depends on vrapper.core in this case
Problems
Many plug-ins solution have some issues with lazy class loading that I don't understand.
It's beacause when instances of modes from vrapper.core are created they need
classes from surround.core to be created (via vrapper.eclipse -> surround.eclipse).
This works if you run stuff from Eclipse and select all plug-ins from run configuration,
but if one deploys features & plugins and run eclipse normally an exception is thrown
because classes from surround.core cannot be found.
It's something in the spirit of surround.core asking for extra commands from
dependent plug-ins creates implicit circular dependencies.
What I mean by implicit dependencies is that no core class depends on eclipse-specific classes in compile time.
Modes (like vim normal mode) are core classes. They contain commands. There are some commands specific for particular Eclipse editors (like run this JDT-specific refactoring). Those commands implement core interfaces, but their code (obviously) lives in eclipse-specific projects. When mode is created it asks underlying platform for some extra commands - those extra commands are implemented in eclipse plug-ins. This is when lazy class loading in eclipse make everything blow up in runtime - classes for extra commands are referenced by extension points, but they are not yet loaded. Boom, exception.
I tried to work this around by using "one plug-in to rule them all" approach.
Having just one plug-in seems to be much better solution to me, but I couldn't make it work cleanly.
Only thing that succeeded for me was quite an ugly hack.
All .core projects had an Ant task that created .jar file with their classes
and dropped it into corresponding *.eclipse project
*.eclipse projects included that jars and had them enlisted in MANIFEST files.
The problem with this ugly hack approach (besides of it being ugly hack) is
that development becomes quite painful. Eclipse code navigation, code coverage
and few other things in Eclipse stops working.
Summary
We have eclipse independent library + eclipse specific stuff architecture,
but we really need all of this to live in one plug-in (because there are some dependencies in both directions).
How do I make code from few projects live into one plug-in/fragment?
It turned out that adding Eclipse-BuddyPolicy: dependent to MANIFEST.MF files, reexporting some dependencies and turning one fragment into plugin (so there is plug-in dependency for BuddyPolicy to track) was the right solution.
Problem solved :-)
From reading this it sounds as if the actual problem is the fact that there are dependencies in both directions. Can't you refactor your projects to make only the Eclipse-spcific proejcts depend on the core projects, and not the other way around?