Maven Philosophie

Man kann Maven am besten vor dem Hintergrund von anderen Build-Werkzeugen wie Ant oder Make verstehen. Ich habe jahrelang alle meine Projekte mit Ant gemanaget. Dadurch ergab sich eine gewisse Standardisierung der Projekte. Ich verwendete immer die selbe bewährt Dateistruktur, immer die selbe Abfolge von Ant-Tasks. In der Regel kopierte ich dann auch die Ant-Build-Datei und passte sie leicht an. Alle Variablen waren richtig gesetzt. Es kam so zu einer Automatisierung der Softwareentwicklung. An dieser Stelle die Maven-Idee an. Maven geht jetzt noch einen Schritt weiter indem Maven davon ausgeht, dass es ein solches Vorgehen bei vielen Softwareentwicklern gibt und automatisiert den Build-Prozess. Dies geschieht auf folgenden Wegen:

• Einführung eines Standard-Lifecycles für den Build-Prozess
• Standard-Dateistruktur fürs Projekt
• Jar-Management
• Plugin-Managment

Das Hauptproblem aus meiner Sicht für Ant-Benutzer ist, dass sich der Lifecycle und auch die Standard-Dateistruktur sich nicht in einer normalen pom.xml widerspiegeln. In Ant oder auch in Make werden nur Dinge ausgeführt, die der Entwickler explizit in den entsprechenden Dateien definiert. In Maven greift hier die Automation, viele Dinge passieren ohne weiteres zutun des Entwicklers. Das man erstmal verkraften. Dazu kommt, dass man dadurch das man keine entsprechenden Anweisungen in der Steuerungsdatei definieren musste, fehlt dem Maven-Einsteiger der offensichtliche Ansatzpunkt um nach seinen Vorstellung das Projekt zu manipulieren. Ein weiterer Stolperstein für Maven-Anfänger oder Umsteiger ist, das der hohe Automatisierungsgrad sich nicht 1:1 durch das Maven-Eclipse-Plugin m2eclipse wieder findet. Dies kann z.B. zu interessanten Fehlern wie dem folgenden führen. Ich habe in Eclipse eine Javaklasse angelegt und dann mir durch Eclipse die passende Testklasse erzeugen lassen. Diese legt Eclipse automatisch im selben Package und im selben Verzeichnis ab. Das führt zu einem Fehler im Maven-Build-Prozess, weil die Testdateien nicht im selben Verzeichnis wie die Klasse liegen dürfen. Ih habe ein bisschen nach diesem Fehler suchen müssen, weil der Code korrekt war, die Dateien sich alle im Build-Path befanden und die Fehlermeldungen nicht auf das eigentliche Problem hinwiesen. In Nicht-Maven-Projekten existiert tritt dieser Fehler nicht auf.