Артефакт Maven та найменування groupId

На даний момент я переношу якийсь проект від Мурахи до Мейвена. Конформістський , як я, я хочу використовувати добре зарекомендували конвенції для пошуку groupIdі artifactId, але я не можу знайти якісь - або докладні угоди (є деякі, але вони не покривають точки я задаюся питанням о).

Візьмемо для прикладу цей проект, спочатку пакет Java: com.mycompany.teatimer

Чайний таймер - це насправді два слова, але конвенції про іменування пакету Java забороняють вставляти підкреслення або дефіси, тому я пишу це разом.

Я вибрав groupIdідентичний ідентифікатору пакету, тому що думаю, що це гарна ідея. Є це?

Нарешті, я повинен вибрати artifactId, на який я пішов teatimer. Але коли я дивлюся на інших проектах Maven, вони використовують дефіс для розділення слів в artifactIdсек, як це: tea-timer. Але це виглядає дивно , коли приєднувалися до groupId: com.mycompany.teatimer.tea-timer.

Як би ти це зробив?

Ще один приклад:

Назва пакету: com.mycompany.awesomeinhouseframework

groupId: com.mycompany.awesomeinhouseframework(?)

artifactId: awesome-inhouse-framework(?)

Ваша умовність здається розумною. Якби я шукав ваші рамки в репоні Maven, я шукав би awesome-inhouse-framework-x.y.jarв com.mycompany.awesomeinhouseframeworkкаталозі груп. І я знайшов би це там, згідно з вашою умовою.

Для мене працюють два простих правила:

• пакети зворотного домену для groupId (оскільки такі досить унікальні) з усіма обмеженнями щодо імен пакетів Java
• назва проекту як artifactId (маючи на увазі, що воно повинно бути зручним для імені jar, тобто не містити символів, які можуть бути недійсними для імені файлу або просто виглядати дивно)

Дивацтво є дуже суб'єктивним, я просто пропоную дотримуватися офіційної рекомендації:

Керівництво по іменуванню конвенцій про groupId, artifactId та версії

• groupIdідентифікує ваш проект однозначно для всіх проектів, тому нам потрібно застосувати схему іменування. Він повинен дотримуватися правил імені пакета, що означає, що він повинен бути як мінімум доменним іменем, яким ви керуєте, і ви можете створити стільки підгруп, скільки вам потрібно. Подивіться докладнішу інформацію про назви пакетів .

  напр. org.apache.maven,org.apache.commons

  Хороший спосіб визначити деталізацію groupId - це використовувати структуру проекту. Тобто, якщо поточний проект є проектом з декількома модулями, він повинен додати новий ідентифікатор до батьківського groupId.

  напр. org.apache.maven, org.apache.maven.plugins, org.apache.maven.reporting

• artifactIdназва банку без версії. Якщо ви створили його, то ви можете вибрати будь-яке ім’я з малих літер і жодних дивних символів. Якщо це сторона третьої сторони, ви повинні взяти назву банки під час її розповсюдження.

  напр. maven,commons-math

• versionякщо ви поширите його, то ви можете вибрати будь-яку типову версію з цифрами та крапками (1.0, 1.1, 1.0.1, ...). Не використовуйте дати, оскільки вони зазвичай асоціюються зі складаннями SNAPSHOT (вночі). Якщо це сторонній артефакт, ви повинні використовувати їх номер версії, як би це не було, і як би дивно це не виглядало.

  напр. 2.0, 2.0.1,1.3.1

Розглянемо наступне, як створити основний перший додаток Maven :

groupId

• com.companyname.project

artifactId

• проект

version

• 0,0.1

Однак я не погоджуюсь з офіційним визначенням Посібника з іменування конвенцій щодо groupId, artifactId та версії, яка пропонує groupId повинен починатися із зворотного доменного імені, яким ви керуєте.

comозначає, що цей проект належить компанії, і orgозначає, що цей проект належить до соціальної організації. Це добре, але для таких дивних доменів, як xxx.tv, xxx.uk, xxx.cn, не має сенсу називати groupId, розпочате з "tv.", "Cn.", GroupId має надавати основну інформацію проекту, а не домену.

Розглянемо це, щоб отримати повністю унікальний файл jar:

• GroupID - com.companyname.project
• ArtifactId - com-companyname-проект
• Пакет - com.companyname.project