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.
target/” >> .gitignore
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:
mvn -Dwtpversion=2.0 eclipse:eclipse
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.
-  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:
Caused by: org.apache.uima.cas.CASRuntimeException:
JCas type "de.tudarmstadt.ukp.teaching.nlp4web.ml.type.NamedEntity" used in Java code, but was not declared in the XML type descriptor.
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:
-  uimaFit Guide and Reference – 8.1. Making types auto-detectable
-  DKPro tutorial (UIMA part): Type System Auto-Discovery (Slide 37)
-  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.
-  Site on “M2E plugin execution not covered”
-  List of “m2eclipse interesting build executions”
The Eclipse IDE offers to perform certain actions each time you save Java source code. These so-called Save Actions can be found here:
Window -> Preferences -> Java/Editor/Save Actions
The following is a list of my personal favorites:
- Format Source Code
Make sure you protect your comments from being formatted. Else the Eclipse formatter may be quite frustrating. Shortcut Ctrl + Shift + F.
- Organize Imports
In most cases this feature allows you to save time when refactoring the code. May also be performed manually using Ctrl + Shift + O.
- Add ‘this’ qualifier to unqualified field accesses/Add ‘this’ qualifier to unqualified method accesses
If you always qualify class members with the this qualifier, you can easily review, e.g. how difficult it may be to refactor out a method. In the rare case that you open your Java sources in a text editor, you may immediately recognize what variables are class members and what methods are static/non-static.
- Convert control statement bodies to block except for single return or throw statement
Often, I am tempted to not wrap one-line blocks below if/else with braces. But it is possible that you will need to add a second line and if you are in a hurry, you will not recognize that the second line is indeed outside the scope of the if/else.
- Add final modifier to private fields/method parameters/local variables
To my opinion, the final qualifier is a valuable means to make the code more expressive in terms of “what will not change from here on”. Unfortunately, there is nothing like the const keyword in C++ available for Java.
- Add missing ‘@Override’ annotations
Similar to the argumentation for final.
When I update a Maven project in Eclipse Juno (m2eclipse version 1.2.0) I sometimes get back an error message reporting:
“Updating Maven Project”. Unsupported IClasspathEntry kind=4
There are some strategies on how to solve this. The most successful in my case is to perform the following steps:
- Disable the Maven Nature of the project by Right-clicking the project and selecting Maven -> Disable Maven Nature
- Fire up a terminal in the projects directory and run
mvn eclipse:clean (Important: the project still needs to be open in Eclipse!)
- Re-enable the Maven Nature of your project by Right-clicking the project and selecting Configure -> Convert to Maven Project
If you now update the project again (Right-click on project -> Maven -> Update Project), everything should run smoothly. If not, you may find additional hints in the stackoverflow question where I drew this solution from.
Another successful solution to this problem is to open up the .classpath file of your project and remove all entries with attribute kind=”var”.
I recently noted that editing multiple XML files in Eclipse Juno results in slow reaction time or even causes Eclipse to hang completely. Fortunately, I found a quick fix for this: The XML editor may easily be replaced. The suggested editor in this case is Rinzo (see here).
The only thing you need to do is install the XML editor, Eclipse will care for replacing the built in XML editor:
- Select Help -> Install New Software…
- In the field Work with: add the URL http://editorxml.sourceforge.net/updates/
- Select Rinzo XML Editor and continue as usual (confirm license agreement etc.)