Anwendung maven groupId Namenskonvention

Question

Ich entwickle eine Reihe von Projekten (derzeit als Eclipse-Projekte organisiert). Es gibt ein Kernprojekt, das hauptsächlich die Kern-API und einige sekundäre Implementierungen und abstrakte Klassen bereitstellt. Alle anderen Projekte hängen von diesem Projekt ab.

Bei der Integration der Projekte in unser Maven-Repository haben wir Probleme mit den Maven-Namenskonventionen. Wie in SO diskutiert, sollte die GroupId in der Regel der umgekehrte Firmendomänenname (com.example) plus der Projektname (com.example.foo) sein. Die Maven-Namenskonventionen schlagen ein zusätzliches Postfix für Unterprojekte wie Plugins vor (com.example.foo.plugin).

In unserem Fall haben wir keine Plugins, sondern mehrere (größtenteils unabhängige) Implementierungen der API, die vom Kernprojekt bereitgestellt werden. Unser aktuelle Namensgebung Vorschlag ist:

• com.example.foo als groupId aller Projekte, auch wenn sie in verschiedene Java-Pakete aufgeteilt werden (com.example.foo enthält die API, com.example.foo.bar enthält die bar Implementierung)
• die Projektnamen als artifactId , ohne ein Präfix

der entscheidende Punkt für das Projekt (bar statt foo-bar) bezieht, ist, dass (obwohl unsere Projekte accross Pakete verteilt sind, wie oben beschrieben) sind sie nicht wirklich sub-p Projekte des API-Kernprojekts.

Entspricht dieser Vorschlag den Namenskonventionen von Maven?

Nur für den Fall: Diese Frage ist nicht, die nach empained Antworten aber für eine argumentative Antwort auf die oben genannte Frage fragen.

Answer 1

Ich würde sagen, das ist eine Frage des eigenen Geschmacks und Ihrer Vorlieben.

Normalerweise würden Sie ähnliche Sätze von Modulen unter demselben groupId gruppieren. Zum Beispiel könnten Sie haben die folgende:

com.foo.bar:parent       (parent pom for all projects) 
com.foo.bar:core-api      (some very core classes) 
com.foo.bar:commons       (some common classes) 
com.foo.bar:io        (some IO classes) 
com.foo.bar:utils       (some utility classes) 
com.foo.bar.messaging:messaging-core  (messaging core classes) 
com.foo.bar.messaging:messaging-rest-api (REST API for messaging) 
com.foo.bar.messaging:messaging-jms   (some JMS code) 
com.foo.bar.web:rest-api     (your restlets) 
com.foo.bar.web:web-core     (core classes to be used by web modules) 
com.foo.bar.web:web-parent     (a parent pom for all your web projects) 
com.foo.bar.web:web-ui      (UI stuff like css/images/js/etc) 
com.foo.bar.web:web-assembly    (a web assembly that bundles all modules) 
... (I hope by now you get my drift) ... 

Sie müssen nicht unbedingt zu einer Gruppe müssen alle Module, deren Klassen beginnen mit einem gemeinsamen Paket unter dem gleichen groupId. Sie könnte tun, dass, wenn Sie mögen, aber das ist selten, wie Menschen es wirklich im wirklichen Leben verwenden. Das Niveau der Strenge und der Größe des Details liegt bei Ihnen, aber im Falle von Artefakten ist es normalerweise nicht so wichtig, da es nichts gibt, was den Paketnamen an die groupId bindet.

Darüber hinaus ist die Verwendung eines Präfixes für Ihre Module ebenfalls hilfreich, aber Ihnen überlassen. Wenn Sie möchten, könnten Sie haben:

com.foo.bar:bar-parent 
com.foo.bar:bar-core-api 
com.foo.bar:bar-commons 

Dies liegt wirklich an Ihnen. Einige werden argumentieren, dass, wenn Sie eine groupId wie com.foo.bar haben, dann brauchen Sie kein bar- Präfix in bar-parent. In gewissem Maße ist dies wahr. Aber dann könnten Sie haben com.foo.bar:parent und com.foo.bar.web:parent und wenn Sie einen Repository-Manager wie Nexus, Archiva oder Artifactory verwenden und Sie suchen nach parent, (oder ein anderer gebräuchlicher Name wie ... commons, zum Beispiel), könnten Sie enden mit einer ziemlich langen Liste von Ergebnissen, im Gegensatz zu bar-parent.

Am Ende kommt es darauf an, auf welchem ​​Detaillierungsgrad Sie stehen und was wirklich Ihren Anforderungen entspricht. Maven bietet Ihnen alle Freiheiten, die Sie in dieser Hinsicht brauchen.

Answer 2

So wie ich es sehe haben Sie eine Reihe von Optionen, die Maven-Namenskonventionen folgen ...

Foo bezieht sich auf die Kern-API und Bar bezieht sich auf die Umsetzung.

1. com.example.foo (bezogen auf den Kern api) als die Gruppe und dann die Umsetzung foo-bar sein (convention sagt man einen Haken zurück in die Gruppe in Ihrem Artefakt Namen enthält).

2. com.example.bar als Thr-Gruppe und der Artefakt-ID ist balken impl oder durch andere geeignete suffix

3. com.example.foo.bar wie die Gruppe, und bar-Umsetz oder durch andere geeignete Suffix .

Für Sie sagen zu dem ungewohnten: die Umsetzung eng mit der API gekoppelt ist und einen eng verwandter Release-Zyklus. Wenn eine neue Version der Kern-API veröffentlicht wird, wird auch eine Version der Implementierung veröffentlicht. Außerdem ist die Implementierung ein Kind der Kern-API und steht nicht wirklich alleine. Sie sagen auch, dass das Kerngeschäft von Bar eine Implementation von Bar ist und abgesehen davon wenig Wert hat (es macht nicht viel anderes).

In Sie sagen, dass die Implementierung der Kern-API hat einen eigenen Lebenszyklus und ist in der Regel nicht auf dem gleichen Zyklus wie die API freigegeben.Außerdem ist es kein Teilprojekt der Kern-API und kann somit für sich alleine stehen. Mit anderen Worten, es ist Kerngeschäft und Nutzung ist nicht nur eine Implementierung von foo. Wenn Bar Geschwister haben kann, ist dies besonders attraktiv.

ist eine mittlere Straße zwischen den beiden. Es sagt, dass bar Wert für sich selbst sowie Bedeutung als eine Implementierung von foo und möglicherweise auch für Geschwister hat. Es verbessert sich leicht gegenüber 2, da es Feedback gibt, dass dieses Artefakt eine Implementierung von foo ist. Auch wenn Bar Geschwister haben kann, macht das mehr Sinn.

Also ich denke, Sie müssten auswählen, wo Ihre Implementierungen der API sitzen. Der größte Treiber ist wahrscheinlich, ob die Bar Geschwister haben kann.

Answer 3

Ich würde sagen, es ist in Ordnung, alle Ihre Artefakte in der gleichen GroupId zu haben. Aber Sie sollten das Sub-Projekt-Muster gegebenenfalls verwenden.

Zum Beispiel hat Feder alle Hauptartefakte in einer GroupId, org.springframework. Dazu gehören der Kern von spring sowie die Teilprojekte JMS, ORM und WMV. Aber größere Unterprojekte wie Spring Boot haben eine separate groupId, org.springframework.boot. Ich würde sagen, dass dies ein gutes Muster ist, dem man folgen muss.

Answer 4

Die Benennung von Dingen ist sehr wichtig und die Namen sollten sofort wichtige Informationen vermitteln. Aus diesem Grund geben die Konventionen, die mein Unternehmen verwendet hat, an, dass die Gruppen-ID für alle Implementierungen einer bestimmten Sache identisch sein sollte: Die Gruppen-ID jeder Gruppe lautet com.example.foo, weil es sich bei allen um Implementierungen handelt.Die Projektnamen sollten auf die Schnittstelle beziehen, und Bindestriche mit dem Namen für ihre besondere Implementierung, mit dem Haupt pom Mutter prominent als ‚Eltern‘ beschriftete:

com.example.foo:parent 
com.example.foo:foo-bar 
com.example.foo:foo-bat 
com.example.foo:foo-baz 

Auf diese Weise auf einem Blick aus den Namen sagen kann, genau wie diese Dinge zusammenhängen, und die Artefaktnamen auch einzeln anzeigen, dass es sich um verschiedene Arten von foo handelt. Dies bedeutet auch, dass Importe im Java-Code genau die gleiche Struktur haben. Es macht Importe auch im Java-Code lesbar und verständlich.