Paket vs Projekt Trennung in Java

Question

Zunächst einmal komme ich (zurück) zu Java von C#, also Entschuldigungen, wenn meine Terminologie oder Philosophie nicht ganz in Einklang steht.

Hier ist der Hintergrund: Wir haben eine wachsende Sammlung von internen Support-Tools für das Web geschrieben. Sie verwenden HTML5/AJAX/andere Buzzwords für das Frontend und Java für das Backend. Diese Tools verwenden ein leichtgewichtiges Inhouse-Framework, so dass sie sich eine Verwaltungsschnittstelle für Sicherheit und andere Konfiguration teilen können. Jedes Tool wurde von einem anderen Autor geschrieben, und ich gehe davon aus, dass dieser Trend anhalten wird. Daher möchte ich es zukünftigen Autoren erleichtern, "standardisiert" auf den Bibliotheken von Drittanbietern zu bleiben, für die wir uns bereits entschieden haben wie DI, Unit-Tests, ORM usw.

sieht derzeit Unser Paket Namensgebung wie folgt aus:

• com.ourcompany.tools.framework
• com.ourcompany.tools.apps.app1name
• com.ourcompany.tools.apps.app2name

... und so weiter.

Also hier ist meine Frage: Sollte jede dieser Anwendungen (und das Framework) als separates Projekt für Maven Setup, Eclipse, etc behandelt werden?

Wir könnten hier im Laufe der Zeit viele Apps erscheinen lassen, also scheint es, als würde die Trennung die Abhängigkeiten sauberer halten und jemand leichter auf ein einzelnes Tool zugreifen können. Auf der anderen Seite ist (1) das "Teilen" von tieferen Teilen einer Paketstruktur über mehrere Projekte ein Code-Geruch und (2) das Zusammenhalten würde Werkzeugschreiber dazu bringen, Bibliotheken von Drittanbietern zu verwenden, die bereits für den anderen vorhanden sind Werkzeuge.

FWIW, mein erster Instinkt ist es, sie zu trennen.

Was sagen Sie, Java-Gurus?

Answer 1

Ich halte meine Projekte getrennt, aber verwenden Sie einen Eltern Pom für alle Abhängigkeiten und andere gemeinsame Eigenschaften. Einzelne Werkzeuge/Projekte haben einen Namen und einen Verweis auf das übergeordnete Projekt und ggf. projektspezifische Abhängigkeiten. Dies hilft bei der Beibehaltung allgemeiner Bibliotheken und Abhängigkeiten, da die üblichen bereits konfiguriert sind, aber ich kann mich auf den speziellen Teil der Codebasis konzentrieren, mit dem ich arbeiten muss.

Answer 2

Ich würde sie absolut trennen. Stellen Sie für Maven sicher, dass jede App/jedes Projekt über die entsprechenden Abhängigkeiten zum Framework/den Apps verfügt, sodass Sie nicht alles erstellen müssen, wenn Sie nur eine App erstellen möchten.

Answer 3

Wenn es einen Abschnitt eines Projekts gibt, der wahrscheinlich für mehr als ein Projekt verwendet wird, ist es sinnvoll, dies herauszuziehen. Es wird es auch ein wenig sauberer machen, wenn Sie den Code in einem der häufig verwendeten Projekte aktualisieren müssen.

Answer 4

Ich würde diese Art von Dingen definitiv in separate Projekte trennen.

Sie sollten Maven verwenden, um den Abhängigkeiten/Build-Prozess automatisch zu behandeln (sowohl für Ihre eigenen internen gemeinsamen Bibliotheken als auch für Abhängigkeiten von Drittanbietern). Es wird kein Problem geben, wenn mehrere Anwendungen dieselben gemeinsamen Bibliotheken referenzieren - Sie können sogar mehrere Versionen bei Bedarf beibehalten.

Paar von Prämien aus diesem Ansatz:

• Dies zwingt Sie sorgfältig über Ihre API-Design für die gemeinsamen Projekte zu denken, was eine gute Sache auf lange Sicht sein.
• Es wird wahrscheinlich auch über die richtige Granularität für Quellcodeverwaltung geben - also Ihre Entwickler überprüfen und

Answer 5

Wenn Sie individuell auf bestimmte Anwendungen oder Backend-Module arbeiten können, sie halten zusammen werden Sie weniger Hindernisse haben die Entwicklung Erstellen und Bereitstellen Ihrer Tools.

Wir hatten die entgegengesetzte Situation, mit vielen verschiedenen Projekten. Nachdem wir sie in einen Projektbaum zusammengeführt haben, sind wir viel produktiver und das ist uns wichtiger als die Konventionen, die sich entwickeln.