Maven Artefakt- und groupId-Benennung

Question

Ich bin gerade dabei, einige Projekte von Ant auf Maven umzustellen. Konformistisch wie ich bin, möchte ich gut etablierte Konventionen für die Suche nach groupId y artifactId aber ich kann keine detaillierten Konventionen finden (es gibt einige, aber sie decken nicht die Punkte ab, über die ich mich wundere).

Nehmen Sie zum Beispiel dieses Projekt, zunächst das Java-Paket: com.mycompany.teatimer

Tee-Timer besteht eigentlich aus zwei Wörtern, aber die Java-Paketnamenskonventionen verbieten das Einfügen von Unterstrichen oder Bindestrichen, also schreibe ich alles zusammen.

Ich habe die groupId identisch mit der Paket-ID, weil ich das für eine gute Idee halte. Ist es das?

Schließlich muss ich eine artifactId habe ich mich derzeit für teatimer . Aber wenn ich mir andere Maven-Projekte ansehe, verwenden sie Bindestriche zur Trennung von Wörtern in artifactId s, etwa so: tea-timer . Aber es sieht komisch aus, wenn es mit der Datei groupId : com.mycompany.teatimer.tea-timer .

Wie würden Sie dies tun?

Ein weiteres Beispiel:

Name des Pakets: com.mycompany.awesomeinhouseframework

groupId : com.mycompany.awesomeinhouseframework (?)

artifactId : awesome-inhouse-framework (?)

Answer 1

Seltsamkeit ist höchst subjektiv, ich schlage nur vor, der offiziellen Empfehlung zu folgen:

Anleitung zu den Namenskonventionen für groupId, artifactId und version

• groupId wird Ihr Projekt identifizieren daher müssen wir ein Namensschema durchsetzen. Es muss den Paketnamen folgen Regeln folgen, was bedeutet, dass der Name mindestens mindestens ein von Ihnen kontrollierter Domainname sein, und Sie können so viele Untergruppen erstellen wie Sie wollen. Siehe Mehr Informationen über Paketnamen .

  Ej. org.apache.maven , org.apache.commons

  Eine gute Möglichkeit, die Granularität der groupId zu bestimmen, ist die Verwendung von die Projektstruktur. Das heißt, wenn das aktuelle Projekt ein Projekt mit mehreren Modulen ist proje Bezeichner an die groupId des übergeordneten Projekts anhängen.

  Ej. org.apache.maven , org.apache.maven.plugins , org.apache.maven.reporting

• artifactId ist der Name der Jar-Datei ohne Version. Wenn Sie es erstellt haben erstellt haben, können Sie jeden Namen wählen, den Sie mit Kleinbuchstaben und ohne seltsame Symbole. Wenn es ein Jar von einem Drittanbieter ist jar handelt, müssen Sie den Namen des jar nehmen, wie es verteilt wird.

  Ej. maven , commons-math

• version wenn Sie es verteilen, können Sie Version mit Zahlen und Punkten wählen (1.0, 1.1, 1.0.1, ...). Verwenden Sie keine Datumsangaben, da diese normalerweise mit SNAPSHOT (nächtliche) Builds. Wenn es sich um eine Artefakt eines Drittanbieters handelt, müssen Sie deren Versionsnummer verwenden, egal wie sie lautet, und so seltsam es auch aussehen mag.

  Ej. 2.0 , 2.0.1 , 1.3.1

Answer 2

Ihre Konvention scheint vernünftig zu sein. Wenn ich nach Ihrem Framework im Maven Repo suchen würde, würde ich suchen nach awesome-inhouse-framework-x.y.jar en com.mycompany.awesomeinhouseframework Gruppenverzeichnis. Und dort würde ich es entsprechend Ihrer Konvention finden.

Für mich gelten zwei einfache Regeln:

• Reverse-Domain-Pakete für groupId (da diese ziemlich eindeutig sind) mit allen schränkt ein. zu den Namen von Java-Paketen
• Projektname als artifactId (der Name sollte jar-freundlich sein, d.h. keine Zeichen enthalten, die für einen Dateinamen ungültig sind oder einfach seltsam aussehen)

Answer 3

Betrachten Sie zunächst die folgenden Punkte als Grundlage für den Aufbau Maven Anwendung:

groupId

• com.companyname

artifactId

• Projekt

version

• 0.0.1

Answer 4

Ich stimme jedoch nicht mit der offiziellen Definition von Anleitung zu den Namenskonventionen für groupId, artifactId und version die vorschlägt, dass die groupId mit einem umgekehrten Domänennamen beginnen muss, den Sie kontrollieren.

com bedeutet, dass dieses Projekt zu einem Unternehmen gehört, und org bedeutet, dass dieses Projekt zu einer sozialen Organisation gehört. Diese sind in Ordnung, aber für diese seltsamen Domains wie xxx.tv, xxx.uk, xxx.cn, macht es keinen Sinn, die groupId mit "tv.", "cn." zu beginnen, die groupId sollte die grundlegenden Informationen des Projekts liefern und nicht die Domain.