Maven - ist es eine gute / gängige Praxis, um es nur für die Abhängigkeit mgmt verwenden und dann lassen Sie die Ant alles andere tun ?

Question

Ich bin ein Neuling in Sachen Maven.

Abgesehen von der Verwaltung von Abhängigkeiten habe ich wenig Verwendung dafür.

Es wurde so schwierig, eine pom.xml zu schreiben, dass ich eine ant build.xml aus einer der Maven-Aufgaben generierte (was eine nette praktische Aufgabe ist...) Ich musste die build.xml, die von Maven generiert wurde, anpassen. Und jetzt werden alle meine Kompilierungen, Tests usw. mit dieser build.xml durchgeführt.

Ist eine solche Kombination üblich? Ich denke daran, sie in meinem Projekt dauerhaft einzusetzen.

Answer 1

Abgesehen von der Verwaltung von Abhängigkeiten habe ich wenig Verwendung dafür.

Das liegt daran, dass du es nicht verstehst :) Die Verwaltung von Abhängigkeiten ist nur ein kleiner Teil von Maven, Maven hat wirklich viel mehr. Zitat Maven: Der endgültige Leitfaden :

Maven ist ein Projektmanagement-Tool, das ein Projektobjektmodell, eine Reihe von Standards, einen Projektlebenszyklus, ein Abhängigkeitsmanagementsystem und eine Logik zur Ausführung von Plugin-Zielen in definierten Phasen eines Lebenszyklus umfasst. Wenn Sie Maven verwenden, beschreiben Sie Ihr Projekt anhand eines wohldefinierten Projektobjektmodells. Maven kann dann übergreifende Logik aus einer Reihe von gemeinsamen (oder benutzerdefinierten) Plugins anwenden.

Maven verwendet Konvention vor Konfiguration mit vielen nützlichen Vorgaben (Verzeichnisspeicherorte, ein definierter Lebenszyklus, eine Reihe von allgemeinen Plugins, die wissen, wie man Software baut und zusammenstellt), bietet Maven eine gemeinsame Schnittstelle um ein Projekt zu erstellen (im Gegensatz zu Ant wissen Sie, wie Sie Dinge wie Tests, Paketierung usw. mit jede Projekt, keine Notwendigkeit, das Build-Skript zu öffnen, um herauszufinden, wie es gemacht wird), implementiert Maven Wiederverwendung durch Maven-Plugins (Build-Logik ist aus DRY-Gründen in Plugins eingebettet, Sie müssen sich nicht immer wiederholen, Sie müssen nicht Teile Ihrer Build-Skripte kopieren/einfügen), Maven hat eine Projekt-Objektmodell die es Ihnen ermöglicht, Ihr Projekt durch Metadaten zu beschreiben (dies ermöglicht Abhängigkeitsmanagement, entfernte Repositories, Wiederverwendung von Build-Logik, Tool-Integration, Artefaktsuche...).

Da Maven also eine Lingua franca oder einer gemeinsamen Sprache für das Projektmanagement, der Vergleich von Maven mit Ant (+ Ivy, wenn Sie wollen), Maven mit Buildr, Maven mit Gradle ist wie der Vergleich von Äpfeln mit Orangen, der Vergleich ist einfach irrelevant.

Ist eine solche Kombination üblich? Ich denke daran, sie in meinem Projekt dauerhaft einzusetzen.

Nun, nein, das ist wirklich nicht die Art und Weise, wie Maven die Dinge angeht. Dies mag verlockend erscheinen (weil Sie das Gefühl haben, dass Sie die Kontrolle zurückgewinnen, weil Sie verstehen, was mit Ant passiert), aber in Wirklichkeit wiederholen Sie sich wieder und verlieren alle Vorteile von Maven. Sicher, es gibt eine gewisse Lernkurve mit Maven und ich sage nicht, dass Sie es in einer Nacht lernen werden, aber wenn Sie es einmal verstanden haben, werden Sie die Macht spüren. Ich würde daher empfehlen, es weiter zu versuchen, Fragen auf der Mailingliste oder hier auf SO zu stellen, das Maven Buch zu lesen, etc. Aber geben Sie nicht auf.

Answer 2

Sie haben also das getan, was Maven Ihnen kostenlos zur Verfügung stellt, indem Sie Ant Tasks innerhalb einer pom.xml schreiben?

Neben dem Dep-Mgmt kompiliert Maven die Quellen, führt alle Testfälle aus und verpackt das Ganze als jar-Datei für Sie, ohne zusätzliche Konfiguration. Das ist die Standardeinstellung.

Es ist nicht üblich, eine pom.xml mit Ant-Wirrwarr anzureichern. Allerdings werden manchmal einige spezielle Aufgaben oder ältere Ant-Aufgaben in den pom.xml-Lebenszyklus eingebettet, aber das sind Ausnahmen und nicht der Regelfall.

Was genau ist schwierig beim Schreiben einer pom.xml ?

Ich frage mich das, weil man das meist nur einmal für ein Projekt macht und nicht ständig damit zu kämpfen hat. Außerdem bieten die meisten IDEs Unterstützung für die Erstellung der minimalen pom.xml, die ohnehin nur aus ein paar Zeilen besteht.

Answer 3

Ich habe Maven ausprobiert, persönlich für private Projekte und beruflich an meinem Arbeitsplatz, und... ich hasse es. Ich muss zugeben, dass ich nicht viel Erfahrung habe, aber es fühlt sich nicht gut an. Ich habe den Eindruck, dass Maven eine nicht ganz so perfekte Umsetzung einer guten Idee ist. Ich werde wahrscheinlich von Maven-Enthusiasten angefeindet werden, aber das ist meine persönliche Meinung.

Ich denke, dass Maven seine Stärken in Organisationen ausspielt, die mit einem Netzwerk von zusammenhängenden Projekten arbeiten, wie es bei Apache der Fall ist; wo Abhängigkeiten dazu neigen, sich häufig zu ändern und ziemlich explizit spezifiziert werden müssen, um die "Jar-Versionshölle" zu vermeiden. Für isolierte Projekte, die von einigen wenigen, sich selten ändernden Jars abhängig sind, finde ich es zu aufdringlich.

Um Ihre Frage zu beantworten: Ich habe in Foren und Blogs im Internet Beiträge von Leuten gelesen, die genau das tun, was Sie propagieren. Sie verwenden Maven für das Abhängigkeitsmanagement und bauen dann mit Ant. Dies untergräbt einige der Vorteile, die Maven bringen soll, wie z.B. die Tatsache, dass ein "normaler" Build in Maven einfacher zu spezifizieren ist als in Ant. Ich denke jedoch, dass Sie durch die Tatsache ermutigt werden können, dass Sie nicht die einzige Person mit dieser Idee sind, und dass es tatsächlich für einige andere Leute funktioniert.

Ich würde Ihnen gerne Links zu Zitaten geben, aber ich bin in den letzten Wochen auf diese Dinge gestoßen und habe keine Referenzen gesammelt.

Answer 4

Ich bin ein Fan von Maven, aber es ist nicht ohne Probleme. An einige der Probleme erinnere ich mich (und kämpfe immer noch):

• Genau wie Ant hat es eine magische Syntax, die schwer zu verstehen sein kann. Wenn Sie mit Any vertraut sind, werden Sie das vielleicht vergessen, aber viele Ant-Aufgaben sind furchtbar dokumentiert. Das Gleiche gilt für Maven. Einer der Gründe, warum ich schließlich auf Maven umgestiegen bin, ist jedoch, dass man bei vielen Mojos (ähnlich wie bei Ant-Tasks) nicht verstehen muss, wie man sie konfiguriert. Man muss nur die verschiedenen Teile an der richtigen Stelle platzieren (was genauso schwierig sein kann wie die Konfiguration einer Aufgabe...).
• Das automatische Abhängigkeitsmanagement ist erstaunlich!... wenn es funktioniert. Wenn Sie Nicht-Maven-Abhängigkeiten verwenden müssen (wie z.B. Hadoop), wird es zu einem Problem. Sie müssen sie entweder als Systemabhängigkeiten referenzieren, jemanden finden, der sie gepackt hat, oder sie selbst paketieren. Und schließlich müssen Sie Ihren eigenen Maven-Proxy, wie Nexus, einrichten. Und das ist ein ganzes Stück mehr an Aufwand.
• Maven ist auf nicht vernetzten oder isolierten LANs ein großes Problem. Die Automagic ist großartig, solange man vernetzt ist.

Answer 5

Es wurde so schwer, eine pom.xml zu schreiben, dass ich eine ant build.xml von einer der Maven-Aufgaben generiert habe (was eine schöne praktische Aufgabe ist...) Ich musste die build.xml, die von Maven generiert wurde, anpassen. Und jetzt werden alle meine Kompilierungen, Tests usw. mit dieser build.xml durchgeführt.

Nun. Sie können Folgendes verwenden Maven-Archetyp-Plugin um Pom zu erzeugen :)

Ist eine solche Kombination üblich? Ich denke daran, sie in meinem Projekt dauerhaft einzusetzen.

JBoss Seam verwendet Maven intern, um Abhängigkeiten zu handhaben und einige Ziele in Maven zu erreichen. Es ist ein großes Projekt, das mit Ant aufgewachsen ist, und jetzt ist es schwierig, das gesamte Projekt ausschließlich in Maven zu bauen, aber das wird in naher Zukunft passieren.