Artefakt Maven i nazwa grupy


291

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(?)


1
Gdzie widzisz grupę powiązaną z artefaktem? Myślę, że konwencje, które wymieniasz, są prawidłowe.
Abhinav Sarkar

2
W rzeczywistości dozwolone są podkreślenia w nazwach pakietów Java, patrz: docs.oracle.com/javase/tutorial/java/package/namingpkgs.html
Adriaan Koster

Odpowiedzi:


146

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)

Ok, jeśli ty i abhin4v myślicie, że to normalne, zrobię to w ten sposób, dziękuję!
Noarth

Uważam, że mieszanka nie-łącznika (awesomeinhouseframework) i łącznika (awesome-inhouse-framework) jest trochę dziwna. Ponieważ groupid nie pozwala na łączniki, trzymałbym się też pisowni bez łącznika dla artefaktu.
Michael Küller

3
Wyjaśnij, co rozumiesz przez „przyjazny dla jar”?
vikramvi

1
Wyjaśnione w odpowiedzi :).
Henryk Konsek,

241

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


4
Znam te konwencje, ale tak naprawdę nie mówią, jak należy stworzyć nazwę artefaktu (nie ma konwencji nazewnictwa JAR) i co zrobić, jeśli byłby taki sam jak groupId - nie widziałem żadnej POM w takim przypadku.
Noarth

@Noarth 1. Nazwa artefaktu zależy od ciebie (ale używanie łączników w nazwie jest powszechną praktyką). 2. Szukasz absolutnej „reguły”, która nie istnieje (co jeśli twoja niesamowita struktura wewnętrzna składa się z kilku modułów?). Zobacz na przykład artefakty: Wiosna, Maven, Hibernacja itp.
Pascal Thivent,

Nie, nie, nie mam żadnych modułów, tylko proste projekty. W rzeczywistości nie mamy projektu o nazwie „niesamowite wewnętrzne ramy” :)
Noarth

11
Co package? Jaka jest różnica w stosunku do groupId?
KonstantinK

1
Czy artefakt może mieć w nim liczby?
theonlygusti

100

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

groupId

  • com.companyname.project

artifactId

  • projekt

version

  • 0.0.1

Czy jako pracę najemną powinienem używać com.my.company.projectjako groupIdlub com.client.company.project?
Giacomo Alzetta,

@GiacomoAlzetta możesz lepiej użyć dowolnego z mrówczanów. Niektóre przykłady „com.companyName.hirePortal” lub „org.compnayName.hirePortal”.
Manwal

3
groupId powinien być com.companyname nie com.companyname.project
Kamil Nekanowicz

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.


2
Ta konwencja uniemożliwia programistom korzystanie z maven, ponieważ przed wdrożeniem artefaktów w centralnym repozytorium maven musisz posiadać domenę. To jest niedorzeczne. Posiadanie domeny może być z roku na rok dość kosztowne.
Tommy.Tang

1
Nie ma wymogu posiadania rejestracji dla tej nazwy domeny. Jedynym wymaganiem jest to, aby identyfikator grupy, który będzie nazwą pakietu Java, nie powodował konfliktu z żadną inną taką nazwą podczas wdrażania. Ta konwencja z pewnością nie uniemożliwia programistom korzystania z Maven.
Basil Bourque,

Dobrą praktyką jest uzyskiwanie nazw pakietów z adresu URL repozytorium. Jeśli korzystasz z GitHub, Twoje konto jest wywoływane myuseri Twoje repozytorium jest wywoływane myrepo, a następnie po prostu użyj nazwy pakietu com.github.myuser.myrepo. To nic nie kosztuje i wciąż jest wyjątkowe.
fxnn

-14

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

  • GroupID - com.companyname.project
  • ArtifactId - com-companyname-project
  • Pakiet - com.companyname.project
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.