Repository-Layout für große Maven-Projekte

Question

Ich habe eine große Anwendung (~50 Module), die eine Struktur ähnlich der folgenden verwendet:

• Anwendung
  • Kommunikationsmodule
    • Farbkommunikationsmodul
    • SSN-Kommunikationsmodul
    • usw.Kommunikationsmodul
  • Router-Modul
  • Servicemodule
    • Abstimmungsdienstmodul
      • Webinterface-Submodul für Abstimmungen
      • Vote-Collector-Submodul für die Abstimmung
      • usw.zum Abstimmen
    • Quiz-Servicemodul
    • usw.Modul

Ich möchte die Anwendung in Maven und Subversion importieren.Nach einiger Recherche habe ich herausgefunden, dass es hierfür zwei praktische Ansätze gibt.

Einer verwendet eine Baumstruktur, genau wie der vorherige.Der Nachteil dieser Struktur besteht darin, dass Sie eine Menge Optimierungen/Hacks benötigen, damit das Multimodul-Reporting mit Maven gut funktioniert.Ein weiterer Nachteil besteht darin, dass in Subversion der Standardansatz Trunk/Tags/Branches das Repository noch komplexer macht.

Der andere Ansatz verwendet eine flache Struktur, bei der es nur ein übergeordnetes Projekt gibt und alle Module, Untermodule und Teile der Untermodule direkte untergeordnete Elemente des übergeordneten Projekts sind.Dieser Ansatz funktioniert gut für die Berichterstellung und ist in Subversion einfacher, allerdings habe ich das Gefühl, dass ich auf diese Weise etwas von der Struktur verliere.

Welchen Weg würden Sie langfristig wählen und warum?

Answer 1

Wir haben eine umfangreiche Anwendung (mehr als 160 OSGi-Bundles, bei denen jedes Bundle ein Maven-Modul ist) und die Lektion, die wir gelernt haben und weiterhin lernen, ist, dass flach besser ist.Das Problem bei der Codierung der Semantik in Ihrer Hierarchie besteht darin, dass Sie an Flexibilität verlieren.Ein Modul, das heute zu 100 % „Kommunikation“ heißt, kann morgen teilweise „Dienst“ sein, und dann müssen Sie Dinge in Ihrem Repository verschieben, was alle möglichen Skripte, Dokumentationen, Referenzen usw. kaputt machen wird.

Daher würde ich eine flache Struktur empfehlen und die Semantik an einer anderen Stelle kodieren (z. B. in einem IDE-Arbeitsbereich oder in einer Dokumentation).

Ich habe eine Frage zum Versionskontrolllayout ausführlich beantwortet mit Beispielen bei einer anderen Frage, es könnte für Ihre Situation relevant sein.

Answer 2

Ich denke, es ist besser, wenn Sie Ihre Verzeichnisstruktur verflachen.Vielleicht möchten Sie eine Benennungskonvention für die Verzeichnisse entwickeln, damit sie beim Betrachten aller Projekte gut sortiert werden, aber letztendlich glaube ich nicht, dass diese zusätzliche Hierarchie notwendig ist.

Angenommen, Sie verwenden Eclipse als Ihre IDE, werden alle Projekte in einer flachen Liste enden, sobald Sie sie importieren, sodass Sie durch die zusätzlichen Unterverzeichnisse nicht wirklich etwas gewinnen.Das und die Tatsache, dass die Konfiguration ohne die ganze zusätzliche Hierarchie so viel einfacher ist, macht die Wahl für mich ziemlich klar.

Vielleicht möchten Sie auch darüber nachdenken, einige der Module zu kombinieren.Ich weiß nichts über Ihre App oder Domäne, aber es scheint, dass viele dieser Module auf Blattebene besser als reine Pakete oder Paketsätze in einem anderen Modul auf oberster Ebene geeignet sind.Ich bin dafür, die Gläser zusammenhängend zu halten, aber das kann manchmal zu weit gehen.