Gradle vs Maven: What builder should I use for my Java projects?

Short Answer

Maven. Maven have some small advantages over Gradle but you drive good with Gradle.

 

TLDR

Gradle Pro

It works, mostly. New features appearing earlier. Great driver for Maven features.

Gradle Con

Some times it doesn't work. 

Semantic changes. 

Log handling is not intuitive.

Build file structure is not so clear like in Maven.

The build.gradle file looks like a mess if some newbie try to adapt, improve, re-structure, optimize the build process. The scripting ability is a clear con. If you think you have to adapt the build process in the build.gradle, think twice maybe your process is the problem.

Maven Pro

Higher stability and fixed well designed build process.

Maven Con

XML is for the upcoming devs a new things to learn. XML is little bit bloating.

Managing Dependencies for Micro Services

Dependency Hell, das kennen viele Softwareentwickler oft aus mature Projekten. Was bedeutet das fuers Projekt?

1. Es kann nicht auf aktuelle Versionen von Libs migriert werden, Java eingeschlossen. Dadurch bleiben nuetzliche Funktionen verschlossen.
2. Das Projekt ist statisch wie Beton und nur unter sehr grossem Zeitauswand aenderbar.
3. CVEs koennen nicht behoben werden.

Um Dependencies effiktiv zum meisten und obige Schwaechen zu umschiffen, hier ein paar Best Pracices im Umgang mit Dependencies.

1. Goldene Regeln
1. Less is more
2. Convention over configuration
   
2. Versuche mit moeglichst wenig Konfigurationen auszukommen.
3. Versiuche moeglichst wenig Dependencies zu benutzen.
   
4. Benutze Parents wenn moeglich.
5.  Benutze Dependeny Management (Maven) wenn es moeglich ist.
   
6. Benutze nur fixe Versionen von Libs wenn sie nicht im Parent verfuegbar sind.
7. Wenn du Excludes/Includes brauchst z.B. um CVEs zu fixen, dann hinterlasse einen entsprechenden Kommentar mit der CVE Nummer. So kann diese Konfiguration spaeter sehr einfach entfernt werden.
8. Update regelmaessig deine Dependencies um keinen Wartungsstau aufkommen zu lassen. Du kannst leicht einen Check Step in der Build Pipeline einbauen die dir Anzahl der outdated Libs ausgibt.
9. Aktuelle Libs verbessern die Sicherheit, aktuelle Libs haben weniger CVEs. 
10. Pruefe ob Dependencies noch benutzt werden
1. Grep isy dein Freunf fuer Compile Scope Dependencies: grep -r com.strange-package src/
2. Organize your imports
   
11. Das Build file ist genauso ein Teil deines Softwareprojetes wie der Code selbst.

 

Gitlab Badges for Maven Jacocoo Test Coverage

1. Integrate Jacoco into your Maven pom.xml.
2. Add into your file .gitlab-ci.yml: echo -n "Total:" ; cat target/site/jacoco/index.html | grep -o 'Total[^%]*%' | grep -o -E '[0-9]+%$
3. Add Badge in Gitlab under Setting.
4. Gitlab scan the console for the Regex you given in Point 3.

1. Integrate Jacoco into your Maven pom.xml.
2. Add into your file .gitlab-ci.yml: echo -n "Total:" ; cat target/site/jacoco/index.html | grep -o 'Total[^%]*%' | grep -o -E '[0-9]+%$
3. Add Badge in Gitlab under Setting.
4. Gitlab scann the console for the Regex you given in Point 3.

Then you you've got this nice Gitlab Test coverage Badge.

Tinkerforge Weather Station published on Github

Tinkerforge is electronics framework for software developers. It's a good starting point for your own Internet of Things (IoT).  So I decide to bye me a starter kit. I choose the weather station kit.

Now, after some time I publish my Tinkerforge Weather Station Java Project on Github (Link). Its simple and robust. It uses callbacks to recognize on sensor changes. and runs over days without problems. It measures humidity, air pressure, ambient light and temperature. The temperature is measured indirectly via chip temperature of the humidity bricklet. Special features are, switching the display light depending on ambient light, show alternating date and time and show warnings because of to low or high humidity. If you put your hand over the ambient light sensor, the sensor works as contactless light switch.

If you are looking for more information on Tinkerforge, you can read the book (Kindle, german only) from Sven Ruppert: Einführung in die Heimautomatisierung: IoT mit Tinkerforge.

Gradle Dependencies und Snapshots

Wer als Softwareentwickler den Snapshot Mechanismus von Maven kennt, wird ihn gerne verwenden. Er bietet eine leichte und einfache Weise Software zu testen über die Grenzen eines einzelnen Projektes hinaus. Leider gibt es diesen Mechanismus in Gradle nicht. Die ist ein wirklicher Nachteil von Gradle im Vergleich zu Maven und es ist nicht der einzige Nachteil. Aber das ist hier nicht das Thema.

In Gradle kann relativ einfach lokale Jar-Dateien, z.B. aus einem anderen Projekt als Dependency einbinden:

 dependencies {

          classpath files('../wpt-gradle-plugin/target/lpt-gradle-plugin-0.0.19-SNAPSHOT.jar')

 }

So lassen sich sehr einfach Software-Artefakte aus anderen Projekten einbinden ohne sie permanent auf einen Nexus hochzuladen. Damit entfällt auch das sehr lästige manuelle hochzuholen der Versionenummern in den beiden beteiligten Projekten. Der Nachteil dieser Lösung ist, dass wenn die Har-Datei selber Abhängigkeiten hat, dann werden diese nicht aufgelöst, weil Gradle die dafür notwendigen Informationen fehlen.

repositories {

          mavenLocal()

 }

 dependencies {

          classpath "de.otto:lpt-gradle-plugin:0.0.19-SNAPSHOT"

 }

Ein einfache Lösung die die Vorteile beider Lösungen kombiniert ist die Benutzung des lokalen Maven Stores zum laden der Entwickler-Jar-Datei und dem laden der Dependencies. Um die Har-Datei in den lokalen Maven stören zu bringen muss mann das Maven Target install ausführen:
...

[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ lpt-gradle-plugin ---

[INFO] Building jar: /Users/mirkoebert/Documents/workspace/wpt-gradle-plugin/target/lpt-gradle-plugin-0.0.19-SNAPSHOT.jar

[INFO] 

[INFO] --- maven-install-plugin:2.4:install (default-install) @ lpt-gradle-plugin ---

[INFO] Installing /Users/mirkoebert/Documents/workspace/wpt-gradle-plugin/target/lpt-gradle-plugin-0.0.19-SNAPSHOT.jar to /Users/mirkoebert/.m2/repository/de/otto/lpt-gradle-plugin/0.0.19-SNAPSHOT/lpt-gradle-plugin-0.0.19-SNAPSHOT.jar

[INFO] Installing /Users/mirkoebert/Documents/workspace/wpt-gradle-plugin/pom.xml to /Users/mirkoebert/.m2/repository/de/otto/lpt-gradle-plugin/0.0.19-SNAPSHOT/lpt-gradle-plugin-0.0.19-SNAPSHOT.pom

[INFO] ------------------------------------------------------------------------

[INFO] BUILD SUCCESS

[INFO] ------------------------------------------------------------------------

[INFO] Total time: 3.195 s

[INFO] Finished at: 2015-01-06T22:48:13+01:00

[INFO] Final Memory: 17M/171M

[INFO] ------------------------------------------------------------------------

HOWTO: Releasing a new Software Version with Maven and Git.

Ausgangslage:

• Versionsverwaltung mit Git und Feature Branches
• Ich befinde mich auf dem Branch development 
• Alle Fehler auch Javadoc Fehler sind beseitigt
• Alle Änderungen commitet und gepushed
• Java
• Maven 3 und SNAPSHOTS
• Nexus

Wie mache aus meiner einer aktuelle Entwicklung ein Release?

1. mvn deploy, um die letzte Development Version als SNAPSHOT im Nexus zu veröffentlichen
2. mvn versions:resolve-ranges, um Dependencies mit Range Angaben zu konkreten Versioen aufzulösen, sonst scheitert der Release-Vorgang
3. mvn versions:use-latest-releases, um die Dependencies zu aktualisieren auf deren letzten Release-Stand
4. git commit, um die Änderungen an der pom.xml in Git Repository zu übertragen
5. git checkout master
6. git merge development
7. mvn release:prepare
8. mvn release:perform
9. git commit, um die Änderungen an der pom.xml in Git Repository zu übertragen
10. git checkout development
11. git merge master

Das beschreibt den kompletten Weg ein Release zu erstellen vom Development Branch und wieder zurück. Ach ja, und natürlich das Testen nicht vergessen.

Wenn etwas schief geht:

1. Entfernen von Tags aus Git:
1. git tag listet alle Tags auf
2. git tag -d tagname entfernt den entsprechenden Git Tag aus dem lokalen Git Repo
3. git push --delete origin tagname entfernt den entsprechenden Git Tag aus dem entfernten Git Repo
2. Test im Release Prozess wirklich überspringen: mvn release:perform -Darguments="-DskipTests" 

Externe JARs in Maven integrieren

Das ist leider unschön, kann aber so realisiert werden:


<dependencies>
<dependency>
<groupId>com.splunk</groupId>
<artifactId>splunk</artifactId>
<version>1.0</version>
<scope>system</scope>
<systemPath>${basedir}/lib/splunk-1.0.jar</systemPath>
</dependency>
</dependencies>


Wichtig: Wenn ich versuche dieses Projekt via exec:java (Link) dann schlägt die Fehl. Das MAven Exec Plugin unterstützt diese externe JARs nicht. Das ist unerwartet und schade. Abhilfe kann hier das Maven Package Plugin schaffen, siehe Link. Dabei wird ein Bigjar bebaut, dass man dann sehr einfach ausführen kann.

Maven Release im Batchbetrieb meistern

1. Setzen der Variable JavaHOME: export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.7.0_06.jdk/Contents/Home
2. Einspielen aller Änderungen ins SVN: svn commit -m "test"
3. Das Release vorbereiten: mvn release:prepare  --batch-mode -Darguments='-Dmaven.test.skip=true'
4. Das Release durchführen: mvn release:perform  --batch-mode -Darguments='-Dmaven.test.skip=true'

Mit der Maven Option --batch-mode wird die Interaktivität von Maven abgeschaltet. Dieser Parameter ist z.B. auch im Jenkins oder Hudson hilfreich. Der seltsame Parameter -Darguments='-Dmaven.test.skip=true' führt zu deaktivieren der Tests, in der Regel ist dies nicht notwendig aber zum Testen oft hilfreich. Die Option -Dmaven.test.skip=true ist beim Release nicht wirksam.

Grails Maven Integration

Es gibt verschieden Wege Grails in Maven zu integrieren, z.B. um den Nexus zu benutzen. Da wäre das Grails Plugin Maven Publisher (Link). Dieses ist für Grails 1.X geeignet, wird aber nicht mehr unterstützt. Damit fällt es aus. Ersetzt wurde das Grails Plugin Maven Publisher durch das Release Plugin (Link), welches für Grails 2.X verfügbar ist. Das funktioniert bei aktuellen Grails Projekten, leider wird das Passwort für den Nexus innerhalb des Projektes gespeichert (grails-app/conf/BuildConfig.groovy), das ist überhaupt nicht groovy, das ist fahrlässig. Damit fällt auch diese Lösung aus. Dritter Versuch, erstellen einer POM Datei aus Grails heraus. Das funktioniert nur leider kompiliert dann nichts mehr, unter Java 7 auf dem Mac (siehe Fehlerausgabe unten). Dies ist ein bekannter Bug (Link).

Fazit, drei Möglichkeiten, kein Treffer. Was macht eigentlich Ant?





[ERROR] Unresolveable build extension: Plugin org.grails:grails-maven-plugin:2.1.0 or one of its dependencies could not be resolved: Could not find artifact com.sun:tools:jar:1.6 at specified path /Library/Java/JavaVirtualMachines/jdk1.7.0_06.jdk/Contents/Home/jre/bundle/Classes/classes.jar @
[ERROR] Unknown packaging: grails-app @ line 8, column 16

at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:339)
at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:632)
at org.apache.maven.DefaultMaven.getProjectsForMavenReactor(DefaultMaven.java:581)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:233)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
[ERROR]  
[ERROR]   The project com.futuretv.userprofiledatasource:UserProfileDatasource:0.1 (/Users/mirkoebert/Documents/workspace-sts-2.9.0.RELEASE/UserProfileDatasource/pom.xml) has 2 errors
[ERROR]     Unresolveable build extension: Plugin org.grails:grails-maven-plugin:2.1.0 or one of its dependencies could not be resolved: Could not find artifact com.sun:tools:jar:1.6 at specified path /Library/Java/JavaVirtualMachines/jdk1.7.0_06.jdk/Contents/Home/jre/bundle/Classes/classes.jar -> [Help 2]
org.apache.maven.plugin.PluginResolutionException: Plugin org.grails:grails-maven-plugin:2.1.0 or one of its dependencies could not be resolved: Could not find artifact com.sun:tools:jar:1.6 at specified path /Library/Java/JavaVirtualMachines/jdk1.7.0_06.jdk/Contents/Home/jre/bundle/Classes/classes.jar
at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:215)
at org.apache.maven.project.DefaultProjectBuildingHelper.resolveExtensionArtifacts(DefaultProjectBuildingHelper.java:377)
at org.apache.maven.project.DefaultProjectBuildingHelper.createProjectRealm(DefaultProjectBuildingHelper.java:237)

Nexus

Der Nexus ist ein Repostory für Java Bibliotheken und Artefakte. Es integriert sich perfekt in Maven. Es gibt neben der freien Version noch ein Professional Version. Ein Vorteil der Professional Version ist, dass man Maven Sites, also Projekt Sites und Reports die durch Maven erzeugt wurden, dort deployen kann. Zur Installation gibt es hier eine Anleitung. Wenn das TGZ zur Installation gewählt wurde ist dringend zu prüfen, ob der Eigentümer und die Gruppe richtig gesetzt sind (root). Dann noch schnell den Benutzer im File /etc/init.d/nexus auf root setzen. Schon läuft der Nexus unter: http://localhost:8081/nexus Benutzername: admin Passwort admin123 (bitte ändern). Jetzt einen Benutzer anlegen und ihm ausreichend Rechte geben. Dann noch Maven konfigurieren, folgende Einträge müssen ins POM:

<distributionManagement> 
    <snapshotRepository> 
        <id>snapshots</id> 
        <url>http://stage02:8081/nexus/content/repositories/snapshots</url> 
    </snapshotRepository> 
    <repository> 
        <id>release</id> 
        <url>http://stage02:8081/nexus/content/repositories/releases/</url> 
    </repository> 
</distributionManagement>

Danach muss noch die user.xml ergänzt werden:

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 
                      http://maven.apache.org/xsd/settings-1.0.0.xsd"> 
  <localRepository/> 
  <interactiveMode/> 
  <usePluginRegistry/> 
  <offline/> 
  <pluginGroups/> 
      <servers> 
            <id>release</id> 
            <username>ebm</username> 
            <password>XXX</password> 
        </server> 
        <server> 
            <id>snapshots</id> 
            <username>ebm</username> 
            <password>XXX</password> 
        </server> 
    </servers> 
  <mirrors/> 
  <proxies/> 
  <profiles/> 
  <activeProfiles/> 
</settings>

Jetzt kann man alles testen: mvn deploy

Code Coverage mit Emma

Für die Berechnung der Testabdeckung des Codes gibt es eine Reihe von Werkzeugen, populär sind Cobertura als auch EclEmma. Cobertura wir gerne in Grails verwandt nur leider liefert Cobertura in Verbindung mit Java 7 keine Ergebnisse mehr. Also auf zu Emma. Emma lässt sich sehr einfach als Eclipse Plugin einsetzen, um Emma auch in Maven 3 nutzen zu können bedarf ein wenig Konfiguration.

    <build> 
        <plugins> 
            <plugin> 
                <artifactId>maven-compiler-plugin</artifactId> 
                <version>2.3.2</version> 
                <configuration> 
                    <source>1.7</source> 
                    <target>1.7</target> 
                </configuration>
            </plugin> 


            <plugin> 
                <groupId>org.jacoco</groupId> 
                <artifactId>jacoco-maven-plugin</artifactId> 
                <version>0.6.0.201210061924</version> 
                <executions> 
                    <execution> 
                        <goals> 
                            <goal>prepare-agent</goal> 
                        </goals> 
                    </execution> 
                    <execution> 
                        <id>report</id> 
                        <phase>prepare-package</phase> 
                        <goals> 
                            <goal>report</goal> 
                        </goals> 
                    </execution> 
                </executions> 
            </plugin>

EclEmma basiert auf der Bibliothek jacococ, dem entsprechend muss das Maven Plugin JACOCO benutzt werden. Mit dieser Maven Konfiguration erzeugt man dann zu Eclipse equivalente Reports.

Maven Basiskonfiguration

Mit Maven 3 hat sich einiges in den Default-Werten geändert. Trotzdem muss man das JDK und das Encoding explizit in der POM Datei angeben:

... 
        <properties> 
        <jdk.version>1.7</jdk.version> 
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> 
        </properties> 
    <organization> 
... 

</project>

So sehen dann die Einstellung zum JDK und zum Encoding in Eclipse aus.

Auch ja, und im PMD Plugin sollten auch die richtige JDK Version gesetzt sein:

... 
                         </plugin> 
                            <plugin> 
                                <groupId>org.apache.maven.plugins</groupId> 
                                <artifactId>maven-pmd-plugin</artifactId> 
                                <version>2.5</version> 
                                <configuration> 
                                    <linkXref>true</linkXref> 
                                    <minimumTokens>100</minimumTokens>
                                    <minimumPriority>5</minimumPriority> 
                                    <targetJdk>1.7</targetJdk> 
                                </configuration>
                            </plugin> 
                    </reportPlugins>
                </configuration>
            </plugin> 
        </plugins> 
    </build> 

Java 7 konfigurieren unter Mac OS X und Eclipse

Java 7 ist endlich für Mac OS X fertig geworden.

• JRE: http://www.oracle.com/technetwork/java/javase/downloads/jre7-downloads-1637588.html
• JDK: http://www.oracle.com/technetwork/java/javase/downloads/jdk7u7-downloads-1836413.html

Aber wie konfiguriert man Eclipse bzw. STS, dass es das neue Java 7 verwendet. Dazu muss man zuerst das neue Java finden (/Library/Java/JavaVirtualMachines/jdk1.7.0_07.jdk/Contents/Home/). Leider kann man diesen Ordner nicht im Eclipse Filechooser auswählen, man muss den Pfad direkt in die Zeile JRE home rein kopieren (siehe Bild unten).

Jetzt muss nur noch ein guter JRE name gesetzt werden. Leider funktioniert dieser Trick bei Open Office nicht.

Damit Maven auch das neue Java 7 benutzt muss die Variable Java_Home gesetzt werden. Am besten editiert man dazu die ~/.profile. Dort fügt man folgende Zeile ein:
export JAVA_HOME="/Library/Java/JavaVirtualMachines/jdk1.7.0_11.jdk/Contents/Home"

Dann benutzt Maven auch das aktuelle Java:

mvn -version
Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: /usr/share/maven
Java version: 1.7.0_11, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_11.jdk/Contents/Home/jre
Default locale: de_DE, platform encoding: UTF-8
OS name: "mac os x", version: "10.8.3", arch: "x86_64", family: "mac"

Schöne neue Maven Welt

Was mich an Maven oder viel mehr an Maven Entwicklern stört, ist dass sie Abhängigkeiten aufbauen statt sie abzubauen. Wenn ich an einem Open Source Plugin eines größeren Systems nur eine Zeile Code ändern möchte, dann  muss ich gleich das ganze System und nicht nur das Plugin auschecken. Das ist absurd. Guter Code hat eine eine geringe Kopplung zwischen Modulen und wenige Abhängigkeiten. Parent Module sind schön aber nicht immer notwendig. Hört auf alle möglichen Features zu nutzen. Jedes neue Feature sollte das Gesamtsystem einfacher und nicht komplizierter machen.

Vergleich von Build Systemen: Ant, Maven und Gradle

JAXenter versucht sich an einem besonderen Vergleich, es wurde versucht die Build Systeme Ant, Maven und Gradle zu vergleichen (Link).

Dabei wurden einige Argumente vorgebracht die nicht richtig sind.

• Ant arbeitet sequenziell aber es ist sehr einfach mehrere Tasks zu parallelisieren. 
• Maven kann ab Version 3 auch mehrere Task benutzen (Link).
• Ant und Maven arbeiten auch inkrementell.
• Maven ist auch in der Lage Ant in den Build einzubeziehen. Wenn auch in Grenzen (Link).

Trotz dieser kleinen Patzer ist es trotzdem nicht uninteressant die Artikel in JAXenter zu lesen.

Maven: Build Jar with Dependencies

Um eine Applikation zu bauen die aus nur einer JAR-Datei besteht nahm ich früher das Maven Shade Plugin (http://programming-2.blogspot.com/2010/05/maven-shade-plugin.html). Dies geht auch einfacher mit Hilfe des, nein nicht des JAR Plugins, sondern mit Hilfe des Maven Assembly Plugins (maven-assembly-plugin). Das sieht dann wie folgt aus:

Maven 3

Von vielen unbemerkt kam ein Major Release von Maven heraus, Maven 3. Ich habe es auch nicht bemerkt, dass ich es schon nutzte. Nach der Installation des Eclipse-Plugins m2eclipse in meinem Brandneuen Eclipse Indigo M4 hatte ich es mir schon eingefangen und nicht bemerkt. Das wichtigste zuerst, Maven 3 ist kompatibel zu Maven 2. Auch bei m2eclipse ändert sich nicht. Die Mavenentwickler haben sich einiger Kritikpunkt angenommen, z.B. der miserablen Maven Performance. Jetzt neu, Maven 3 arbeitet inkrementel, d.h. es wird nicht immer ein Clean Build gemacht, sondern nur geänderte Dateien aktualisiert des weiteren kann Maven jetzt auch parallel arbeiten. Mittels des Kommandozeilenparameters -T arbeitet Maven mit mehren Threads. Wie schnell Maven jetzt ist kann nur ein direkter Vergleich zeigen. Auf jeden Fall verkürzt hier Maven 3 den Unterschied zu ANT.

And the winner is ... ANT

Heute bin ich mit meinem ersten Projekt von Maven zu Ant migriert. Der Aufwand ist überschaubar und das neue Ant-File auch. Das Maven-File umfasste 92 Zeilen wohingegen das Ant-File nur 58 Zeilen umfasste. Eine Ersparnis von  37%, nicht mitgerechnet habe ich da die notwendigen Erweiterungen der Maven Konfigurationsdateien. Leider habe ich noch kein Werkzeug gefunden, dass bei diesen Vorgang unterstützt.
Jetzt funktioniert alles wie gedacht nur das Dependency Management muss ich noch per Ivy ergänzen. Am Besten geht man wie folgt vor:

1. Sichern des aktuellen Standes des Projekts z.B. im SVN (kurze Anleitung zum Aufsetzen und starten eine SVN Servers unter Linux)
2. Erzeuge ein neues Verzeichnis im Root-Verzeichnis des Projekts, welches die benötigten Bibliotheken aufnimmt z.B. mkdir lib/
3. Zeige dir alle von Maven verwalteten Bibliotheken an in dem die pom.xml öffnest.
4. Kopiere alle direkt abhängigen Bibliotheken aus dem lokalen Maven Repository in das neue Verzeichnis lib, cp /Users/mirkoebert/.m2/repository/commons-io/commons-io/1.4/commons-io-1.4.jar lib/
5. Ergänze in der build.xml einen Ausdruck der alle JARs im Verzeichnis lib in den Classpath einbindet (siehe Bild oben). 
6. Deaktivieren des Dependency Managements mit Maven in Eclipse.
7. Entfernen der Maven Dependencies aus dem Build Path des Projekts und ergänzen der JARs aus dem Verzeichnis lib/.
8. Löschen der pom.xml aus dem Projektverzeichnis.
9. Entfernen der Maven-Reste aus den Eclipse-Projektdatei (.project, diese Datei kann man mit dem View Navigator anzeigen und öffnen).
1. Entfernen Maven-Builders entweder via Menü in den Projekteinstellungen oder man löscht den zweiten buildCommand-Block (siehe Bild unten)
2. Entfernen der Maven-Natur durch löschen der zweiten nature-Zeile (Bild unten)

Maven Shade Plugin

Shade ist ein nützliches Maven Plugin, mit dem man sogenannte BIGJARs bauen kann, also JARs die alle notwendigen Libs enthalten. Dies ist z.B. beim Testen der Applikation in der Kommandozeile sinnvoll. Leider gibt es zwei Plugins die auf SHADE hören, wenn ich es in Eclipse hinzufügen möchte. Das Plugin, das ich suchte muss mit dem Suchstring maven-shade gesucht werden.
Nach dem man das richtige Plugin der POM hinzugefügt hat muss man es natürlich konfigurieren:

<plugin>
<groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-shade-plugin</artifactId>
 <version>1.3.3</version>
 <executions>
          <execution>
            <phase>package</phase>
            <goals>
              <goal>shade</goal>
            </goals>
            <configuration>
              <transformers>
                <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                  <mainClass>de.fbn.bio.benchmark.Benchmark</mainClass>
                </transformer>
              </transformers>
            </configuration>
          </execution>
        </executions>
</plugin>