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.


When using JUnit for creating unit tests, I have always felt annoyed that Eclipse keeps on suggesting (or even auto-importing) junit.framework.Assert, which is actually a deprecated type but appears first in the list of import suggestions.

To disable this behavior, one has to change the so-called Access Rules for the JUnit library.

To do this:

  1. Right-click you project and select Build Path -> Configure…
  2. Switch to Libraries tab and locate the used junit.jar
  3. Select Access rules and press Edit.
  4. Add a new rule with the rule pattern junit/framework/Assert and set its access level to Forbidden.
  5. Make sure that the rule appears before the junit/framework/* rule, which permits any acccess.

Now, Eclipse should only provide for one import quick fix, when using Assert. Even “Organize Imports” (Ctrl+Shift+O) should automatically find the correct solution now.

Thanks to this Stackoverflow post for hinting me at this solution.

This article shortly describes how to set up the correct editor (+ correct syntax highlighting) for C++ template implementation files (extension: tpp) in Eclipse.

Syntax highlighting

Go to Window -> Preferences, then navigate to General -> Content Types. In the tree view on the right, go to Text -> C Source File -> C++ Source File -> C++ Header File and press Add… As Content Type enter *.tpp.

Do not close the preferences, yet.

File association

In Preferences, open General -> Editors -> File Associations. Press Add… and, as File Type, enter *.tpp . The editors list view at the bottom should contain the C/C++ Editor and Text Editor.


Thanks to JohnP@stackoverflow for describing this solution.

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

public void setUp() throws Exception {

Download as XML


Name: After
Context: Java
Description: JUnit tearDown method

public void tearDown() throws Exception {

Download as XML

EcoreUtil offers two similar methods: remove(EObject) and delete(EObject).


This method removes an object from its containing resource/containing object. However, the removed object remains intact. (see also EMF 2.5 doc)


This method removes an object from the model, thereby deleting all links to other objects. (see also EMF 2.5 doc)

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:

public static final String PARAM_PARAMETER = "parameter";
@ConfigurationParameter(name = PARAM_PARAMETER, mandatory = false, description = "Description", defaultValue = "true")
private boolean parameter;

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


public static final String PARAM_${paramNameCapitalized} = "${paramName}";
@ConfigurationParameter(name = PARAM_${paramNameCapitalized}, mandatory = false, 
    description = "${description}", defaultValue = "${defaultValue}")
private ${type} ${paramName};${cursor}

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


public static final String PARAM_${paramNameCapitalized} = "${paramName}";
@ConfigurationParameter(name = PARAM_${paramNameCapitalized}, mandatory = true, description = "${description}")
private ${type} ${paramName};${cursor}

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:

${imp:import(org.apache.uima.UimaContext, org.apache.uima.resource.ResourceInitializationException)}

public void initialize(final UimaContext context) throws ResourceInitializationException

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:


public void collectionProcessComplete() throws AnalysisEngineProcessException

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)

Infinitest is a really great plugin for Eclipse. It executes all JUnit tests it can find whenever something changes. After I downloaded DKPro core, a multi-module Maven project, may CPU was running for quite a long time, until all unit tests had been executed once – even though I just wanted to look at the code…

To keep Infinitest from executing these tests over and over again on the next occasion, I put an infinitest.filters file in every single of the 72(!) modules as follows:

# Prepare file with regex that matches all test cases
echo ".*" > /tmp/infinitest.filters

# Go to the directory of the aggregator project de.tudarmstadt.ukp.dkpro.core-asl and then
find . -name "de*" -maxdepth 1 -type d -exec cp /tmp/infinitest.filters {} \;

Surely, there is also a one-liner that solves the problem, but one works very reliable for me :-)