Artefakt Maven i nazwa grupy

Obecnie jestem w trakcie przenoszenia projektu z Ant do Maven. Konformistyczny, tak jak ja, chcę używać ustalonych konwencji do wyszukiwania groupIdi artifactId, ale nie mogę znaleźć żadnych szczegółowych konwencji (są pewne, ale nie obejmują one kwestii, o których zastanawiam się).

Weźmy na przykład ten projekt, najpierw pakiet Java: com.mycompany.teatimer

Licznik czasu herbaty to tak naprawdę dwa słowa, ale konwencje nazewnictwa pakietów Java zabraniają wstawiania znaków podkreślenia lub łączników, więc piszę to wszystko razem.

Wybrałem groupIdidentyczny z identyfikatorem pakietu, ponieważ uważam, że to dobry pomysł. Czy to jest

Wreszcie muszę wybrać artifactId, na który obecnie poszedłem teatimer. Ale kiedy patrzę na innych projektów Maven, używają myślniki rozdzielić słowa artifactIds, tak: tea-timer. Ale to wygląda dziwnie, gdy dołączona do groupId: com.mycompany.teatimer.tea-timer.

Jak byś to zrobił?

Inny przykład:

Nazwa paczki: com.mycompany.awesomeinhouseframework

groupId: com.mycompany.awesomeinhouseframework(?)

artifactId: awesome-inhouse-framework(?)

Twoja konwencja wydaje się rozsądna. Gdybym szukał twojego frameworka w repozytorium Maven, szukałbym awesome-inhouse-framework-x.y.jarw com.mycompany.awesomeinhouseframeworkkatalogu grup. I znajdę to tam zgodnie z twoją konwencją.

Działa dla mnie dwie proste zasady:

• pakiety odwrotnej domeny dla groupId (ponieważ są one dość unikalne) ze wszystkimi ograniczeniami dotyczącymi nazw pakietów Java
• nazwa projektu jako artefactId (pamiętając, że powinna być przyjazna dla jar-name, tzn. nie może zawierać znaków, które mogą być niepoprawne dla nazwy pliku lub wyglądać dziwnie)

Dziwność jest wysoce subiektywna, proponuję tylko przestrzegać oficjalnej rekomendacji:

Przewodnik po konwencjach nazewnictwa dla groupId, artefactId i wersji

• groupIdzidentyfikuje Twój projekt w sposób unikalny we wszystkich projektach, dlatego musimy wymusić schemat nazewnictwa. Musi przestrzegać reguł nazw pakietów, co oznacza, że ​​musi to być co najmniej nazwa domeny, którą kontrolujesz, i możesz utworzyć tyle podgrup, ile chcesz. Zobacz Więcej informacji o nazwach pakietów .

  na przykład. org.apache.maven,org.apache.commons

  Dobrym sposobem na określenie ziarnistości groupId jest użycie struktury projektu. Oznacza to, że jeśli bieżący projekt jest projektem wielomodułowym, powinien dołączyć nowy identyfikator do groupId nadrzędnego.

  na przykład. org.apache.maven, org.apache.maven.plugins, org.apache.maven.reporting

• artifactIdto nazwa słoika bez wersji. Jeśli go utworzyłeś, możesz wybrać dowolną nazwę małymi literami i bez dziwnych symboli. Jeśli jest to słoik innej firmy, musisz wziąć nazwę słoika, gdy jest dystrybuowany.

  na przykład. maven,commons-math

• versionjeśli go rozpowszechnisz, możesz wybrać dowolną typową wersję z cyframi i kropkami (1.0, 1.1, 1.0.1, ...). Nie używaj dat, ponieważ są one zwykle związane z kompilacjami SNAPSHOT (nocnymi). Jeśli jest to artefakt innej firmy, musisz użyć jego numeru wersji, niezależnie od tego, co to jest, i tak dziwnie, jak to może wyglądać.

  na przykład. 2.0, 2.0.1,1.3.1

Zastanów się, jak zbudować podstawową pierwszą aplikację Maven :

groupId

• com.companyname.project

artifactId

• projekt

version

• 0.0.1

Nie zgadzam się jednak z oficjalną definicją Przewodnika po konwencjach nazewnictwa dla groupId, artefactId i wersji, która sugeruje, że groupId musi zaczynać się od kontrolowanej przez ciebie odwróconej nazwy domeny.

comoznacza, że ​​ten projekt należy do firmy i orgoznacza , że ten projekt należy do organizacji społecznej. Są w porządku, ale dla tych dziwnych domen, takich jak xxx.tv, xxx.uk, xxx.cn, nie ma sensu nazywać nazwy grupy, która zaczęła się od „tv”, „cn.”, Grupa powinna dostarczyć podstawowe informacje projektu, a nie domeny.

Rozważ to, aby uzyskać w pełni unikalny plik jar:

• GroupID - com.companyname.project
• ArtifactId - com-companyname-project
• Pakiet - com.companyname.project