Nommage des artefacts Maven et des groupId

Question

Je suis actuellement en train de transférer certains projets de Ant à Maven. Conformiste comme je le suis, je veux utiliser des conventions bien établies pour trouver groupId y artifactId mais je ne trouve pas de conventions détaillées (il en existe, mais elles ne couvrent pas les points sur lesquels je me pose des questions).

Prenez ce projet par exemple, d'abord le paquet Java : com.mycompany.teatimer

Minuterie à thé est en fait deux mots, mais les conventions de dénomination des paquets Java interdisent l'insertion de traits de soulignement ou de traits d'union, c'est pourquoi je les écris tous ensemble.

J'ai choisi le groupId identique à l'ID du paquet parce que je pense que c'est une bonne idée. C'est le cas ?

Enfin, je dois choisir un artifactId J'ai opté pour teatimer . Mais lorsque je regarde d'autres projets Maven, ils utilisent des traits d'union pour séparer les mots dans les documents suivants artifactId comme ceci : tea-timer . Mais il a l'air bizarre lorsqu'il est concaténé à l'adresse suivante groupId : com.mycompany.teatimer.tea-timer .

Comment feriez-vous ?

Un autre exemple :

Nom du paquet : com.mycompany.awesomeinhouseframework

groupId : com.mycompany.awesomeinhouseframework ( ?)

artifactId : awesome-inhouse-framework ( ?)

Answer 1

La bizarrerie est hautement subjective, je suggère simplement de suivre la recommandation officielle :

Guide des conventions de dénomination pour groupId, artifactId et version

• groupId permettra d'identifier votre projet de manière unique parmi tous les projets, donc nous devons appliquer un schéma de nommage. Il doit suivre les règles de nom de paquet ce qui signifie qu'il doit être au moins au moins un nom de domaine que vous contrôlez, et vous pouvez créer autant de sous-groupes que vous voulez. Regardez Plus d'informations sur les noms de paquets .

  eg. org.apache.maven , org.apache.commons

  Une bonne façon de déterminer la granularité du groupId est d'utiliser la fonction la structure du projet. C'est-à-dire que si le projet actuel est un projet à modules multiples multiple, il doit ajouter un nouvel identifiant au groupId du parent.

  eg. org.apache.maven , org.apache.maven.plugins , org.apache.maven.reporting

• artifactId est le nom du jar sans version. Si vous l'avez créé alors vous pouvez choisir le nom que vous que vous voulez avec des lettres minuscules et sans symboles étranges. Si c'est un jar d'une tierce partie vous devez prendre le nom de la jar tel qu'il est distribué.

  eg. maven , commons-math

• version si vous le distribuez, vous pouvez choisir n'importe quel type de produit. version avec des chiffres et des points (1.0, 1.1, 1.0.1, ...). N'utilisez pas de dates car elles sont généralement associées aux SNAPSHOT (nightly) builds. S'il s'agit d'une artefact tiers, vous devez utiliser leur numéro de version, quel qu'il soit, et aussi étrange que cela puisse paraître.

  eg. 2.0 , 2.0.1 , 1.3.1

Answer 2

Votre convention semble être raisonnable. Si je cherchais votre framework dans le repo Maven, je chercherais à trouver awesome-inhouse-framework-x.y.jar en com.mycompany.awesomeinhouseframework le répertoire des groupes. Et je l'y trouverais selon votre convention.

Deux règles simples fonctionnent pour moi :

• reverse-domain-packages pour groupId (puisque ceux-ci sont assez uniques) avec tous les contraint concernant les noms des paquets Java
• le nom du projet comme artefactId (en gardant à l'esprit qu'il doit être compatible avec le nom de jar, c'est-à-dire qu'il ne doit pas contenir de caractères non valides pour un nom de fichier ou simplement bizarres)

Answer 3

Considérez les points suivants pour construire la première base Maven application :

groupId

• com.companyname.project

artifactId

• projet

version

• 0.0.1

Answer 4

Cependant, je ne suis pas d'accord avec la définition officielle de Guide des conventions de nommage sur groupId, artifactId et version qui propose que le groupId doit commencer par un nom de domaine inversé que vous contrôlez.

com signifie que ce projet appartient à une entreprise, et org signifie que ce projet appartient à une organisation sociale. Ceux-ci sont corrects, mais pour ces domaines étranges comme xxx.tv, xxx.uk, xxx.cn, cela n'a pas de sens de nommer le groupId en commençant par "tv.", "cn.", le groupId devrait fournir les informations de base du projet plutôt que le domaine.

Answer 5

Considérez ceci pour obtenir un fichier jar totalement unique :

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