Ant oder Maven?

[Humpatz]

Hallo,

ich habe die Aufgabe für ein bestehendes Java-Projekt ein Build-Tool einzuführen und anschließend den Build-Prozess zu automatisieren.

Welches der beiden Build-Tools eignet sich denn aus welchen Gründen besser für dieses Vorhaben?

Eine Automatisierung im Sinne eine Continious Build bzw. Nightly Builds könnte mann ja dann mit Zusatztools wie Cruise Control, Hudson oder Continium erreichen, oder?

Vielen Dank bereits im Voraus für die Hilfe!

 

[Wildcard]

Mit Maven kannst du doch immer noch Ant-Scripte schreiben, Maven kann lediglich mehr (Repository).

 

[maki]

Maven 2, eindeutig

Google bietet doch genug Gegenüberstellungen.

Kurz: ant ist kein richtiges Build tool, kann aber dazu gemacht werden, während Maven 2 ein spezialisiertes Build tool (komplette tool chain) ist.
Während man bei ant alles selbst schreiben muss, hat Maven2 dank der Spezialisierung bereits Konventionen & Plugins für so ziemlich alles was den build Prozess betrifft, man kommt mit viel weniger Aufwand ans Ziel, inklusive Einarbeitung in neue Projekte.

 

[kama]

Hallo,

ganz klares Statement in Richtung Maven 2:

• Projektübergreifende Vereinheitlichung des Build-Prozesses, ausgelegt auf komplexe Multi-Projekt-Strukturen
• Definition eines einheitlichen Build-Lifecycles
• Management von komplexen Abhängigkeiten inkl. transitiven Abhängigkeiten
• Automatische Erzeugung einer Projekt-Site mit Projektinformationen
• Abhängigkeiten, Reports (Qualität, Testfallabdeckung, …)
• Veröffentlichung der Builds in Repositories (zentral, eigene) und Zugriff auf zentrale Repositories
• Erweiterbarkeit und Anpassbarkeit durch Plugin-Konzept (zahlreiche Plugins vorhanden z.B. für Deployment, ANT-Aufrufe)

Vereinheitlichung des Build Prozesse, Dependency Management (auch transitive Abhängigkeiten)

Wichtigeste Regel in Maven: Konvention über Konfiguration

Das bedeutet ein bestehendes Projekt auf die Konventionen von Maven 2 anzupassen!

Aber bitte nicht die Einarbeitung in Maven 2 unterschätzen....auch den Umstellungsaufwand nicht unterschätzen....vor allem bei komplexen EAR Projekten etc.

MfG
Karl Heinz Marbaise

 

[Humpatz]

Vielen Dank für die schnellen und ausführlichen Antworten

... bei meiner Recherche ist mir auch aufgefallen, dass Maven 2 wohl umfangreichere Fkt. mit sich bringt, jedoch kann ich bisher leider nicht die Tragweite einschätzen, wenn ich das bestehende Projekt auf die Koventionen von Maven 2 anpassen muss

Wenn ich es aber aus den Antworten richtig lese, lohnt es sich wohl diesen Aufwand in "Kauf" zu nehmen und dafür von den Vorteilen zu profitieren ... Richtig?

Danke!

 

[maki]

Wenn ich es aber aus den Antworten richtig lese, lohnt es sich wohl diesen Aufwand in "Kauf" zu nehmen und dafür von den Vorteilen zu profitieren ... Richtig?

Absolut richtig!

Allein die Zeitersparnis beim einrichten von Projekten in IDEs, zB. Eclipse, macht vieles wieder gut.
Was früher mind. 1 Tag (im besten Fall) dauerte geht nun in 10-20 Minuten, ganz nebenbei ist man unabhängig von der IDE

 

[Wildcard]

Was früher mind. 1 Tag (im besten Fall) dauerte geht nun in 10-20 Minuten, ganz nebenbei ist man unabhängig von der IDE

Wenn man allerdings bereit ist sich auf eine IDE festzulegen, dann geht es dank Eclipse Buckmister vollautomatisch. Einfach eine URL eintragen die ein entsprechendes Buckminster Query enthält, dann baut sich der Workspace zusammen :wink:

 

[maki]

Buckminster nutzt doch auch die Maven repos

Jedenfalls kann ich mit M2 jederzeit mal schnell die neue Version der IDE testen, Umstellung (samt SVN & M2 Plugin installaiton) < 1 Stunde.

Einen CI Server (Hudson, Continuum, etc. pp.) einrichten ist ein Witz, dauert weniger 2 Stunden um das Ding läuft, ausserdem kann ich mit m2 auch von der Kommandozeile builden, in einer Zeile:
mvn install

Unn nie wieder jars herumkopieren...

 

[Wildcard]

Buckminster nutzt doch auch die Maven repos

Maven ist eine mögliche Quelle für Buckminster

 

[Humpatz]

Nocheinmal eine kleine Verständnisfrage, da ich mich mit dem ganzen Thema bisher nur recht oberflächlich beschäftigt habe:

Wenn ich ein bestehendes Projekt auf die Konventionen von Maven 2 anpassen muss, heißt das dann demzufolge, dass ich die existierende Projektstruktur ändern muss?
Im konkreten Fall existiert ein "mittelgroßes" Java-Projekt mit einer Vielzahl von Paketen.

Muss das alles umgestellt werden, was am Ende ja auch Auswirkungen auf viele Klassen haben würde, die untereinander in Abhängigkeit stehen.

Ich wäre dankbar, wenn ihr etwas konkreter auf die Konventionen eingeht, die einen Maven 2 vorschreibt

Danke!

 

[maki]

>> da ich mich mit dem ganzen Thema bisher nur recht oberflächlich beschäftigt habe

Wieso eigentlich?

Eine der Maven2 Konventionen ist, dass die Java Sourcen getrennt von anderen Ressourcen wie zB. Property- und XML Dateien sind.
Eine andere ist, dass die Unittests von den eigentlichen Klassen getrennt sind.
Mehr fallen mir im Moment gar nicht ein

Diese Trennung ist imho sehr sinnvoll, so kann man ohne Probleme eine Konfig für den eigentlichen Betrieb nehmen und eine andere für die Tests, auch kann man so die Testklassen im selben Packet haben wie die zu testenden Klassen, trotzdem bleiben die Sourcen getrennt.

Klassische Maven 2 Struktur:
src/main/java - Für die Java KLassen
src/main/ressources - Properties/XML Dateien
src/test/java - Für die Testklassen
src/test/ressources - Properties/XML Dateien für die Testklassen

Und das wars dann auch schon.
Packetnamen müssen nicht geändert werden, die eigentliche Packetstrutkur bleibt auch 100% erhalten, es wird einfach alles an die richtiger Stelle im Dateisystem gesetzt, die POM geschrieben und fertig.

Habe schon 2 Projekte (ein EAR und eine Webapp) konvertiert, im Falle einer EAR ist es ein bisschen aufwändiger Aufgrund der vormals miesen Projektstruktur, die webapp war sehr schnell konvertiert.

Eine Anwendung die als jar ausgelifert wird in sehr schnell Konvertiert, eine Frage von ein paar Stunden.