When moving a legacy project from Ant to Maven, I needed to change the default source (default: src/[main|test]/java) and resources (default: src/[main|test]/resources) directories in Maven. These settings may be configured in the <build> element of the project’s pom.xml.

  • <sourceDirectory> the directory where the sources of your application are stored
  • <testSourceDirectory> the directory where the sources of your test cases are stored
  • <resources> the resources of your main application
  • <testResources> the resources needed only by your test cases

The relevant part of the pom.xml in Maven 2.1.x and above looks like this (with default values):



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.


You can delete a remote branch topic_branch located in the repository origin using the git push command:

git push origin :topic_branch

The semantics is that you push an empty reference (before the colon) to the remote branch and therewith delete it.


It may happen that you create a local branch and forget to make it track a remote branch. We can make up for this by using the –set-upstream-to option of the git branch command. Say we are currently on branch issue123 and we want to make this branch track origin‘s issue123 branch.

For Git versions >=1.8

git fetch # may be necessary in order to get origin/issue123
git branch --set-upstream-to=origin/issue123 issue123

For Git versions <= 1.7

Mind the switched order of arguments. This command will also work in later Git versions:

git branch --set-upstream issue123 origin/issue123


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:

  1. Disable the Maven Nature of the project by Right-clicking the project and selecting Maven -> Disable Maven Nature
  2. Fire up a terminal in the projects directory and run mvn eclipse:clean  (Important: the project still needs to be open in Eclipse!)
  3. 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:

  1. Select Help -> Install New Software…
  2. In the field Work with: add the URL http://editorxml.sourceforge.net/updates/
  3. Select Rinzo XML Editor and continue as usual (confirm license agreement etc.)


If a single file becomes too large, e.g., in order to be sent via mail, you may want to split it into parts.

The command line tool tar is perfectly suitable for this, as it stems from an era where backups were regularly performed using tape drives (which have a certain size limit, of course). We will “misuse” this capability of tar in the following.

I suppose your file is called large_file.tar and you want to split it into parts of size 5MB (= 5120KB). The following instructions are not limited to tar files, any single file will do fine as well.

Splitting up the File

You start creating the archive with the following command:

tar -c -M --tape-length 5120 --file=split_archive_part1.tar large_file.tar

As long as there is some unprocessed portion of the original file, you will be prompted for more “volumes”, i.e., more tapes. If you’d use a tape drive, you would now switch the tape, but in our setting we give an additional file for the second part by responding as follows  (note the preceeding “n ” in front of the file name):

Prepare volume #2 for `split_archive_part1.tar' and hit return: n split_archive_part2.tar

For a 22.5MB large file the whole procedure already becomes quite tedious:

tar -c -M --tape-length 5120 --file split_archive_part1.tar large_file.tar
Prepare volume #2 for `split_archive_part1.tar' and hit return: n split_archive_part2.tar        
Prepare volume #3 for `split_archive_part2.tar' and hit return: n split_archive_part3.tar            
Prepare volume #4 for `split_archive_part3.tar' and hit return: n split_archive_part4.tar        
Prepare volume #5 for `split_archive_part4.tar' and hit return: n split_archive_part5.tar

This question-answer game will continue until the whole file has been processed. If you want to save space, you may now compress the resulting archives:

gzip -c split_archive_part1.tar > split_archive_part1.tar.gz && rm split_archive_part1.tar
gzip -c split_archive_part2.tar > split_archive_part2.tar.gz && rm split_archive_part2.tar
# and so on...

Merging the Fragments

Of course, you (or the person who receives the fragmented archive from you) need to be able to restore the original file. The “mirror-symmetric” command to tar -c is tar -x:

tar -x -M --file=split_archive_part1.tar

The following procedure is identical to the other direction. If you use the compressed fragmented archives, you still need to decompress each of them:

gzip -d split_archive_part1.tar.gz

Afterwards the fragmented archives are merged in order to restore the original file:

tar -x -M --file=split_archive_part1.tar 
Prepare volume #2 for `split_archive_part1.tar' and hit return: n split_archive_part2.tar
Prepare volume #3 for `split_archive_part2.tar' and hit return: n split_archive_part3.tar
Prepare volume #4 for `split_archive_part3.tar' and hit return: n split_archive_part4.tar
Prepare volume #5 for `split_archive_part4.tar' and hit return: n split_archive_part5.tar

You should now see large_file.tar in the same directory.


Thanks to Paul Bradly, who described this procedure on his site.