it-swarm-eu.dev

Teilen eines großen Projekts, um ein Maven-Projekt mit mehreren Modulen zu erstellen

Ich arbeite an einer Spring-MVC-Anwendung, in der wir Maven für das Abhängigkeitsmanagement verwenden. Da das Projekt groß ist, denken wir darüber nach, das Projekt in mehrere Teile aufzuteilen. Ich hatte einige Zweifel, auf die ich hier hoffentlich Antworten bekommen werde.

Derzeit stellen wir eine einzelne WAR-Datei als ROOT.war Auf Apache Tomcat auf unserem Server bereit. Da das Projekt groß ist, gibt es Teile in der Webanwendung wie Benachrichtigungen und E-Mail, Dienste von Drittanbietern, Push (Cometd), REST-APIs usw. Derzeit sind alle von ihnen in Clubs zusammengefasst und voneinander abhängig. Beispielsweise hängt das Objekt Notification auch vom Objekt Person ab, da Benachrichtigungen auf Benutzer zugeschnitten sind.

Die Hauptabsicht der Aufteilung des großen Projekts besteht darin, in der Lage zu sein, an einzelnen Modulen zu arbeiten, Fehler zu beheben, Funktionen hinzuzufügen, zu testen usw. Und wenn Sie zufrieden sind, kann nur dieses Modul auf dem Server anstelle der gesamten Anwendung ersetzt werden. Ist das möglich?

Wie bereits erwähnt, gibt es Abhängigkeiten und Zuordnungen zwischen Objekten. Wie werden diese über verschiedene Untermodule hinweg verwaltet? oder ändern sich nur die Importanweisungen, um andere Projekte einzuschließen?

Wie gesagt, es ist beabsichtigt, an einzelnen Modulen zu arbeiten und diese bereitstellen zu können (vorzugsweise heiß). Derzeit haben wir nur eine einzige WAR-Datei als ROOT.war. Wird beim Teilen mehrere Kriegsdateien erstellt, die dann per URL als domain-name.com/module_name/some_mapping Bezeichnet werden?

Ich überprüfe derzeit die Dokumentation, aber dies ist das Hauptziel, das wir mit einem von Maven bereitgestellten Multimodul erreichen möchten, und interessiert zu wissen, ob dies machbar ist. Wenn weitere Informationen erforderlich sind, lassen Sie es mich bitte wissen.

Derzeit verwende ich ein übergeordnetes POM aus dem Frühjahr wie folgt:

<parent>
    <groupId>io.spring.platform</groupId>
    <artifactId>platform-bom</artifactId>
    <version>1.1.3.RELEASE</version>
    <relativePath />
</parent>
25
We are Borg

Ist es möglich ?

Ja sicher. Ich habe in der Vergangenheit einige Projekte wie dieses strukturiert, hier einige Teile, von denen ich hoffe, dass sie Ihnen den Einstieg erleichtern.

Es gibt zwei Hauptmerkmale von Maven, mit denen Sie Dinge zusammenweben können:

Teilen und erobern

Sie müssen Ihre Projekte in mehrere unabhängige Projekte aufteilen. Mit unabhängig meine ich hier, dass alle Verweise auf Code außerhalb des Projekts über Abhängigkeiten in Maven erfolgen und nicht direkt den Quellbaum zusammenführen.

Abhängig vom Status Ihres Quellbaums kann dies viel Arbeit bedeuten. Das heißt, Sie tun es nicht, um Maven einen Schuhlöffel zu geben, sondern um Ihre Codebasis zu strukturieren und zu bereinigen. Betrachten Sie es als Ihren Werkzeugschuppen, der hier viel einfacher zu finden ist:

(Nice toolshed

als hier:

(Not-so-Nice toolshed

Maven verlässt sich stark auf Konvention Je besser Ihre Sachen organisiert sind, desto mehr kann Maven Ihnen helfen. Das heißt, es kann erforderlich sein, dass Sie sich neu organisieren, um besser zu seiner eigenen Konvention zu passen, und wenn ich hier einen Rat geben muss, ist es VIEL einfacher, Ihre Inhalte an die Konventionen von Maven anzupassen, als zu versuchen, Maven zu konfigurieren Verstehe deine Konvention.

Wenn diese Projekte außerhalb der Hauptanwendung verwendet werden könnten, könnten sie als wirklich unabhängige Bibliotheken leben und durch Maven-Abhängigkeiten eingeschlossen werden. Sie sollten in ihrem eigenen Repository (nicht im Quellbaum der Anwendung) gespeichert sein und nicht von einem Teil der Hauptanwendung abhängen.

Kernteile Ihrer Anwendung können nach der Aufteilung in Projekte als Module zusammengestellt werden. In der Regel werden sie als Unterordner des Hauptquellordners Ihrer App abgelegt.

Auch Ihr übergeordnetes POM für Ihre App enthält die Moduldeklaration. Dort platzieren Sie auch alle gängigen Abhängigkeiten für Ihre App und deklarieren die meisten Build-Plugins und deren Konfiguration. Ich empfehle Ihnen auch hier dringend, eine Gruppe von Eigenschaften für Dinge wie die Version der Anwendung zu platzieren, die Sie in den Modulen wiederverwenden können. Es ist viel einfacher zu verwalten, wenn alle dieselbe Version haben und wenn die Version an einem Ort ist, funktioniert dies einfach.

Werkzeuge

Wenn Sie ein Team größer als 1 sind, würde ich auch dringend empfehlen, ein Repository für Ihre Maven-Abhängigkeiten zu installieren. Schauen Sie sich Artifactory , Nexus oder Archiva an. Sie können die POM-Datei so konfigurieren, dass sie direkt auf diesen installiert wird. Sobald sie ausgeführt wird, sollte dies keinen großen Aufwand bedeuten, spart Ihrem Team jedoch viel Zeit beim Auflösen der Abhängigkeiten mit dem richtigen JAR an der richtigen Stelle.

Zum Thema Werkzeug ist der nächste logische Schritt hier ein kontinuierliches Integrationssystem ( Jenkins , es gibt noch viel mehr). Es wird sich darum kümmern, die Quelle zu erstellen, in der die Tests ausgeführt werden, und an das Artefakt zu senden. Wenn dies alles vorhanden ist, müssen Sie nur den Code bearbeiten und der Rest funktioniert einfach.

Da Sie Ihre App als Krieg verpacken Maven kann den Krieg erstellen und alle Abhängigkeiten an den richtigen Stellen platzieren, ohne JAR-Dateien oder ähnliche Arbeiten zusammenführen zu müssen, also keine Sorge.

Beispiel

Ich könnte hier viel länger weitermachen, aber nichts ist besser als ein gutes Beispiel. Suchen Sie auf github nach Projekten ähnlicher Größe und sehen Sie, wie sie ihre POM-Dateien und Ordnerhierarchien erstellt haben. Schauen Sie sich mehr als eine an, einige passen besser zu Ihrem Setup als andere, keine ist wirklich inkarniert the Wahrheit, aber Sie sollten genug finden, um Ihre Gedanken darüber zu beflügeln, wie Sie es erreichen können.

Nehmen Sie zum Beispiel Jenkins :

Sie können sehen, dass ihre übergeordnete POM ziemlich umfangreich ist.

Sie verwenden Module, wie Sie in diesem Abschnitt sehen können:

<modules>
    <module>core</module>
    <module>war</module>
    <module>test</module>
    <module>cli</module>
</modules>

Und jedes Modul entspricht einem gleichnamigen Unterordner, der auch ein POM enthält. Du könntest so viele nisten, wie du willst, aber halte es innerhalb der Vernunftsstufen;).

Fangen Sie klein an

Wenn Sie Maven noch nie benutzt haben, würde ich vorschlagen, dass Sie nicht sofort mit Modulen beginnen. Nehmen Sie es langsam, beginnen Sie mit einer der einfacheren Bibliotheken, die Sie möglicherweise haben, und machen Sie daraus ein Maven-Projekt. Dann machen Sie Ihre Hauptanwendung zu einem einfachen Maven-Projekt. Sobald dies funktioniert, fügen Sie einfache Abhängigkeiten hinzu, teilen Sie dann Ihr erstes Modul auf und so weiter.

Maven ist ein großartiges Werkzeug, aber es kann auch ein super Schmerz im Nacken sein, besonders wenn die Dinge nicht in Ihre Richtung gehen. Mit dem ganzen Whammy auf Anhieb zu beginnen, ist ein Empfänger für eine Katastrophe (war für mich!).

Wenn die Dinge etwas seltsam sind, können Sie jederzeit den Befehl mvn help:effective-pom Verwenden, um zu sehen, was Maven tatsächlich verstanden hat.

plugins

Aus Ihrem Kommentar verstehe ich besser, was Sie erreichen wollen. In diesem Fall würde ich mich für Plugins entscheiden. Erstellen Sie ein Projekt, das die API von Erweiterungspunkten verfügbar macht, an denen Sie die Arbeit isolieren möchten. Dann können Sie dies als Abhängigkeit in einem neuen Projekt verwenden, das es implementiert. Fügen Sie in Ihrer Hauptanwendung einfach die richtigen Abhängigkeiten für diese Implementierungen hinzu (diesmal ohne Maven-Module), und Sie sollten bereit sein. Schließlich wird das Hauptanwendungsprojekt fast keinen Quellcode enthalten, der in externen Projekten ausgeführt und über Abhängigkeiten geladen wird.

Sie müssen jedoch die gesamte Anwendung mit diesem Ansatz erneut bereitstellen, unabhängig davon, ob sich der Kern geändert hat oder nicht, da der Krieg statisch aus den Abhängigkeiten aufgebaut ist. Wenn Sie eine davon ändern, müssen Sie das Ganze neu erstellen. Es klingt schlimmer als es tatsächlich ist. Tatsächlich werden nur die neuen Änderungen tatsächlich erstellt, der Rest ist im Grunde eine Kopie der vorherigen Gläser. Da sich jedoch alles in der Kriegsdatei befindet, muss es neu erstellt werden, und der Server muss gestoppt und neu gestartet werden.

Wenn Sie weiter gehen müssen, werden die Dinge etwas komplizierter, wenn auch nicht unmöglich. Ich würde empfehlen, dass Sie sich mit OSGI befassen. Apache Felix könnte Ihnen den Einstieg erleichtern, obwohl es auch andere Implementierungen gibt. Auf diese Weise können Sie das externe Glas nehmen und es in die richtigen Plugins verwandeln. Sie erhalten viel mehr Kontrolle über den Laufzeitlebenszyklus der Komponenten, die die Tür für dynamisches Neuladen und Aktualisieren öffnen. Es wird jedoch wieder größere Änderungen an Ihrem Kern erfordern, wahrscheinlich kein guter Ausgangspunkt. Sobald Sie jedoch ein Projekt haben, das gut getrennt ist und alle Teile wie gewünscht isoliert haben, kann dies ein natürlicher nächster Schritt sein, wenn das Starten und Stoppen der Anwendung beim Update ein großes Problem darstellt.

Der grundlegende Unterschied zwischen Modulen und Abhängigkeiten ist folgender:

  • Module befinden sich im selben Quellbaum wie die Hauptanwendung, idealerweise als Unterordner.
  • Abhängigkeiten können überall sein.

Sie finden die Bibel hier .

Hoffe das hilft, viel Glück.

23
Newtopian