A behavior that annoyed me for some time was that Eclipse disabled autobuild (“Project -> Build Automatically”) on startup, no matter whether it was active during a previous, regular shutdown of the workspace.

I was unable to find a suitable setting in the workspace settings.

Finally, it turned out that the described behavior can be turned off (and on), by modifying an Eclipse Oomph configuration file as follows:

  1. Navigate to HOME/.eclipse/org.eclipse.oomph.setup/setups .
  2. Open the XML file user.setup .
  3. Navigate to a setupTask XML element with the key /instance/org.eclipse.core.resources/description.autobuilding , and set the value to true.

In my settings file, the corresponding XML fragment looks like this:



By coincidence I recently found out how to open an Eclipse workspace via drag and drop on Windows.

It is actually a simple trick, but I want to share it anyway:

  1.  Create a link to the eclipse.exe that you want to use (e.g., named EclipseWorkspaceDragAndDrop on your Desktop).
  2. Open the properties of the link (e.g., via Alt+Enter).
  3. Locate the Target input field, whose content should end in eclipse.exe right now.
  4. At the very end of the input field, append -data.
  5. Open the Explorer (or suchlike), navigate to the parent directory of your workspace directory, and drag the workspace directory onto the link (e.g., EclipseWorkspaceDragAndDrop)
  6. Eclipse should startup into the selected workspace without asking you to choose one.


For an auto-testing sceanrio on Windows, I needed to start a number of Eclipse instances, each one with a particular workspace of system tests. In case of problems, I wanted  to quickly(, i.e., automatically) stop all instances. For starting and for stopping the instances, I created two Powershell scripts.

Starting Eclipse

When starting Eclipse, all we have to do is store the process id of each instance. Thanks to PowerShell being object-oriented, this is relatively easy. The Start-Process cmdlet returns a process instance when called with the parameter -PassThru, which can be queried for its Id property. We cache the process ids in a line-by-line manner to stop each instance later on.

Stopping Eclipse

A plethora of methods for stopping processes using PowerShell exists. Basically, you need to get a process object (using Get-Process) and call the Kill or Terminate method on it.

Unfortunately, Eclipse kept running after killing its correspondent process: Get-Process eclipse | Stop-Process .

The reason is that Eclipse spawns a child process running javaw.exe. This is the process that needs to be stopped, but killing it leads to an ugly error message. So the method of choice is to call CloseMainWindow() on the javaw process, which triggers the same action as pressing on the ‘X’ in the top-right corner. The remaining challenge is to find out, which of the running javaw processes belong to which Eclipse instance. This can be achieved with the cmdlet Find-ChildProcess as described by Tobias Weltner. The complete scripts looks as follows:



In a previous post, I suggested Java code templates for standard UIMA/uimaFit structures.
In this post, I add two more templates, this time for JUnit’s “setUp” and “tearDown” methods.

To add these templates to your Eclipse workspace, open the Eclipse preferences via Windows -> Preferences. And navigate to Java -> Editor -> Templates.
Either you use the provided XML files and select Import… or you create a new template with New… and copy the text from below.


Name: Before
Context: Java
Description: JUnit setUp method

Download as XML


Name: After
Context: Java
Description: JUnit tearDown method

Download as XML

In a previous post, I described how to simplify the task of creating initialize and collectionProcessComplete methods using Eclipse templates. A similar technique can be applied to generate the idiomatic code for a uimaFit configuration parameter.

The shape of UIMA configuration parameters

An example of configuring UIMA components using uimaFit’s @ConfigurationParameter looks like this:

This snippet demonstrates some best practices that the community or I introduced:

  • The name-giving constant (here: PARAM_PARAMETER) is always public and bears the name of the parameter field as its value (here: “parameter”)
  • You should always provide a default value for non-mandatory parameters. The defaultValue property is always a String and the toString method normally cannot be applied due to compile time restrictions.
  • If a defaultValue attribute is given, uimaFit injects the default value automatically. That means that after the initialize method is complete, parameter has the value true.

For mandatory configuration parameters, only two parts have to be changed:

  1. There is no more defaultValue.
  2. The attribute mandatory is set to true.

Template for optional parameters

In order to create a new code template, open Window -> Preferences -> Java/Editor/Templates and Use the following metadata:

  • Name: uima_optional_param
  • Context: Java
  • Description: Generates an optional uimaFit configuration parameter


When you now type uima_optional_param in an editor, you will be prompted for the different parts of the template:

  • type is the type of the new parameter. You may choose any primitive type (int, boolean,…), any class that has a ‘single String’ constructor (e.g. File), enum types, and Locale/Pattern.
  • paramName is the parameter name. In Java, you should camel-case it, e.g. shallDeleteAll would be a valid parameter name.
  • paramNameCaptialized is the capitalized form of the parameter name. You should follow Java coding conventions, as illustrated in the following example: Parameter shallDeleteAll yields the  constant PARAM_SHALL_DELETE_ALL.
  • defaultValue is the default value of the configuration parameter. It will be injected into the class member by uimaFit.

Template for mandatory configuration parameters

Most things that I described about optional configuration parameters also apply to mandatory configuration parameters. The template for mandatory parameters can be created as follows: Create a new code template in Window -> Preferences -> Java/Editor/Templates and use the following metadata:

  • Name: uima_mandatory_param
  • Context: Java
  • Description: Generates a mandatory uimaFit configuration parameter


The variables in the template have the exact same meaning as in the template for optional parameters.


  • [1] uimaFit wiki on @ConfigurationParameter

When I write UIMA annotators/consumers in Java, often code needs to be executed before and after the processing of all CASes. For this purpose, the base classes for annotators (JCasAnnotator_ImplBase) and consumers (JCasConsumer_ImplBase) offer two methods:

  • initialize(UimaContext) gets called in the beginning and
  • collectionProcessComplete() get called when the complete collection has been processed

Re-typing the skeletons of these two methods is tedious and you may even forget to execute the essential super.initialize(UimaContext) in the first method (otherwise your component will be in a rotten state!).

In Eclipse you can create templates for such tasks. Open Window -> Preferences -> Java/Editor/Templates and select New. We create templates for both methods separately.


Use the following metadata:

  • Name: uima_init
  • Context: Java
  • Description: Generates a stub of the overriden initialize(UimaContext) method.

As pattern:

Besides the known Java code, the pattern defines that ResourceInitializationException should be imported and that the cursor is located after the call to super.initialize.

The template can be inserted by typing uima_init in the editor and selecting the template from the menu via Enter.


Use the following metadata:

  • Name: uima_complete
  • Context:  Java
  • Description: Generates a stub of the overriden collectionProcessComplete() method.

As pattern:

Besides the known Java code, the pattern defines that AnalysisEngineProcessException should be imported and that the cursor is located inside the new method.

The template can be inserted by typing uima_complete in the editor and selecting the template from the menu via Enter.


  • [1] Stackoverflow thread with many useful templates (or links to them)
  • [2] JCasConsumer_ImplBase (uimaFit 2.0.0)
  • [3] JCasAnnotator_ImplBase (uimaFit 2.0.0)

Maven-managed Eclipse projects generate appropriate project settings (classpath, build path, etc.) from the pom.xml. The following files need to be ignored in a Maven Eclipse project:

As a shorthand, the following Bash command adds these lines to your .gitignore. It does not matter if your .gitignore is located in the project directory or in any parent of it.

echo “.settings
target/” >> .gitignore


  • [1] gitignore man page

By a “Maven web project” I mean a Maven project which has War packaging instead of Jar (in pom.xml: <project><packaging>war</packaging></project>). When importing such projects, Eclipse may not be able to figure out that the produced War artifact may be deployed on a server.

Maven may configure your Eclipse project to support WTP:

This goal can also be run inside Eclipse when you right-click the project and then select: Run as -> Maven build… As goal you type in eclipse:eclipse and add a new line in the parameter table where the parameter name is wtpversion and the value is 2.0.

Running the eclipse:eclipse goal for an existing project does not affect any unrelated settings in you project.


  • [1] Maven eclipse plugin: WTP Support

The toolkit uimaFIT allows you to design annotation types in the so-called Component Descriptor Editor, save the descriptor as XML and generate the corresponding Java classes. When you run an analysis engine that makes use of these annotations uimaFit checks whether it finds the type system descriptor XML file on the classpath. In certain circumstances, it may happen that it falls short of finding this file and will abort with the following error message:

In this case you need to explicitly point uimaFIT to the location of your type descriptor file. For this to be done, there exist two different ways.

Solution via VM argument

As a quick and dirty solution you add the following VM argument which in Eclipse is configured in the Launch Configuration dialog

In my case, I stored the XML file in src/main/resources/desc/types/TypeSystem.xml where src/main/resources is set to be a source folder in Eclipse (Maven project layout).

Solution via types.txt (suggested)

The issue with the solution above is that your code will break if other people try to execute it without knowing about the VM parameter. There exists a more stable way to solve this issue. uimaFIT looks into the file

  • <classpath>/META-INF/org.uimafit/types.txt  (for uimaFit until 1.4.x, still supported by the uimafit-legacy-support package)
  • <classpath>/META-INF/org.apache.uima.fit/types.txt (for uimaFit 2.0.0 and above)

in order to find out where to search for the XML type descriptor files (In a Maven context META-INF should be located in src/main/resources). Each line in this types.txt file describes one search pattern. In our example, types.txt should contain one line:


  • [1] uimaFit Guide and Reference – 8.1. Making types auto-detectable
  • [2] DKPro tutorial (UIMA part): Type System Auto-Discovery (Slide 37)
  • [3] TypeDescriptorDetection

If you have executions in your pom.xml which run during so-called interesting build phases. You need to provide a rule how m2eclipse shall deal with these executions (<execute/>,<ignore/>,<delegate/>).

The following snippet may be put into the pom.xml in order allow for the dependency plugin to run the goal build-classpath (Mind the <execute/> directive):

It is very(!) important to give a version range, otherwise a NullPointerException will be thrown.


  • [1] Site on “M2E plugin execution not covered”
  • [2] List of “m2eclipse interesting build executions”