Bedeutet dies, dass das Client-Artefakt eine Laufzeitabhängigkeit vom Impl-Artefakt haben sollte?

Nein und es gibt keine Abhängigkeit (oder sollte besser nicht sein). Sehen Sie sich die Importanweisungen in den Klassen und Schnittstellen des Clientartefakts an, und Sie werden feststellen, dass das Clientartefakt nicht von Implementierungen abhängig ist.

Wenn der Client von der Implementierung abhängig wäre, würde er das Abhängigkeitsinversionsprinzip verletzen, das Teil der SOLID Prinzipien.

  

Oder sollten diese "zirkulären" Abhängigkeiten vermieden werden, auch wenn eine Richtung kompiliert wird und die andere Laufzeit ist?

Tatsächlich wird zur Laufzeit eine Implementierung benötigt, aber das ist eine Frage der Baugruppenmontage. Man könnte die Implementierung eines Tages oder aus Testgründen ersetzen wollen. Es wäre also keine gute Idee, der Implementierung eine Maven-Abhängigkeit im Client-Artefakt hinzuzufügen, um die Komponenten-Assemblierung ein wenig einfacher zu machen.

Stattdessen sollten Sie die Implementierungsabhängigkeit in der EAR-Bereitstellungseinheit deklarieren, da die EAR die Assembly der Unternehmensanwendung ist.

BEARBEITEN

  

Unsere Entwickler beschweren sich, dass mühsame manuelle Arbeit, um sicherzustellen, dass jeder Kunde einen entsprechenden Impl im Ohr hat. Man sucht nach allen Client-Artefakten in der Abhängigkeitsliste, fügt alle entsprechenden Impl-Artefakte hinzu, ruft die Abhängigkeit auf: Liste erneut, fügt alle fehlenden Impl-Artefakte usw. erneut hinzu.

Ich denke, sie nehmen die JEE-Entwicklungsrollen Beschreibung Wort für Wort.

  

Ein Softwareentwickler führt die folgenden Aufgaben aus, um eine EAR-Datei mit der Java EE-Anwendung bereitzustellen:

     

• Erstellt EJB-JAR- und WAR-Dateien, die in den vorherigen Phasen erstellt wurden, in einer Java EE-Anwendungsdatei (EAR)

  

• Gibt den Implementierungsdeskriptor für die Java EE-Anwendung (optional) an

  

• Überprüft, ob der Inhalt der EAR-Datei korrekt formatiert ist und der Java EE-Spezifikation entspricht

  

Trotzdem heißt es in der Spezifikation auch

  

Der Assembler oder der Deployer kann den Implementierungsdeskriptor direkt bearbeiten oder tools verwenden, die XML-Tags entsprechend der interaktiven Auswahl korrekt hinzufügen.

Ich würde sagen, dass das a ear pom ein Beispiel für eine Assembly-Beschreibung mit einem Werkzeug ist.

JF Meier erwähnte auch

  

Einige Entwickler schreiben Skripte für diesen Prozess, aber dann, nachdem man die Versionen einiger ejbs geändert hat, muss man den Prozess wiederholen, weil vielleicht irgendwo tief im Abhängigkeitsbaum ejb-clients gelöscht oder hinzugefügt wurden, also zusätzliche Impls könnte notwendig sein.

Für mich sind diese Skripte die gleichen wie die ear pom. Vielleicht flexibler, aber um den Preis von Standards und Konventionen. Die Tatsache, dass sie die Skripte mit jedem Release aktualisieren müssen, macht deutlich, dass es besser wäre, wenn diese Versionen auch von maven aktualisiert würden.

Außerdem ... Da das Ohrpom nur ein Artefakt der Maven ist, kann es auch in einem Repository eingesetzt werden. Dies ist besser als private Skripts, auf die außer dem Autor niemand Zugriff hat.

Ich hoffe, dass diese Argumente Ihnen bei der Diskussion der Einsatzstrategie mit Ihren Kollegen helfen werden.