Artefacto Maven y denominación de Id. De grupo

291

Actualmente estoy en el proceso de trasladar algún proyecto de Ant a Maven. Conforme soy, quiero usar convenciones bien establecidas para encontrar groupIdy artifactId, pero no puedo encontrar ninguna convención detallada (hay algunas, pero no cubren los puntos sobre los que me pregunto).

Tome este proyecto por ejemplo, primero el paquete Java: com.mycompany.teatimer

El temporizador de té es en realidad dos palabras, pero las convenciones de nomenclatura del paquete Java prohíben la inserción de guiones bajos o guiones, así que lo escribo todo junto.

Elegí el groupIdID idéntico al paquete porque creo que es una buena idea. ¿Lo es?

Finalmente, tengo que elegir un artifactId, actualmente fui por teatimer. Pero cuando miro a otros proyectos Maven, que utilizan guiones para separar palabras en artifactIds, de esta manera: tea-timer. Pero parece raro cuando concatenado a la groupId: com.mycompany.teatimer.tea-timer.

¿Cómo harías esto?

Otro ejemplo:

Nombre del paquete: com.mycompany.awesomeinhouseframework

groupId: com.mycompany.awesomeinhouseframework(?)

artifactId: awesome-inhouse-framework(?)

maven-2 naming-conventions Noarth
fuente
1
¿Dónde ves el groupId concatenado con el artifactId? Creo que las convenciones que declaras son las correctas.
Abhinav Sarkar
2
En realidad, los guiones bajos están permitidos en los nombres de paquetes de Java, consulte: docs.oracle.com/javase/tutorial/java/package/namingpkgs.html
Adriaan Koster,

Respuestas:

146

Su convención parece ser razonable. Si estuviera buscando su marco en el repositorio de Maven, lo buscaría awesome-inhouse-framework-x.y.jaren el com.mycompany.awesomeinhouseframeworkdirectorio del grupo. Y lo encontraría allí según su convención.

Dos reglas simples funcionan para mí:

  • paquetes de dominio inverso para groupId (ya que son bastante únicos) con todas las restricciones con respecto a los nombres de paquetes Java
  • nombre del proyecto como artifactId (teniendo en cuenta que debe ser amigable con el nombre de jar, es decir, no debe contener caracteres que pueden ser inválidos para un nombre de archivo o simplemente verse raros)
Henryk Konsek
fuente
Bien, si tú y abhin4v piensan que es normal, lo haré así, ¡gracias!
Noarth
Encuentro un poco extraño la combinación de no guiones (awesomeinhouseframework) y guiones (awesome-inhouse-framework). Dado que el groupid no permite guiones, me quedaría con la ortografía sin guiones para el artefacto también.
Michael Küller el
3
Por favor, aclare qué quiere decir con "nombre de jar amigable"?
vikramvi
1
Aclarado en la respuesta :).
Henryk Konsek
241

La rareza es altamente subjetiva, solo sugiero seguir la recomendación oficial:

Guía para convenciones de nomenclatura en groupId, artifactId y versión

  • groupIdidentificará su proyecto de manera única en todos los proyectos, por lo que debemos aplicar un esquema de nomenclatura. Tiene que seguir las reglas del nombre del paquete, lo que significa que debe ser al menos como un nombre de dominio que controle, y puede crear tantos subgrupos como desee. Mire Más información sobre los nombres de paquetes .

    p.ej. org.apache.maven,org.apache.commons

    Una buena manera de determinar la granularidad de groupId es utilizar la estructura del proyecto. Es decir, si el proyecto actual es un proyecto de varios módulos, debe agregar un nuevo identificador al groupId del padre.

    p.ej. org.apache.maven` org.apache.maven.plugins` org.apache.maven.reporting

  • artifactIdes el nombre del jar sin versión. Si lo creó, puede elegir el nombre que desee con letras minúsculas y sin símbolos extraños. Si se trata de un jar de terceros, debe tomar el nombre del jar tal como está distribuido.

    p.ej. maven,commons-math

  • versionsi lo distribuye, puede elegir cualquier versión típica con números y puntos (1.0, 1.1, 1.0.1, ...). No use fechas, ya que generalmente están asociadas con compilaciones SNAPSHOT (todas las noches). Si se trata de un artefacto de terceros, debe usar su número de versión, sea lo que sea, y por extraño que parezca.

    p.ej. 2.0` 2.0.1`1.3.1

Pascal Thivent
fuente
44
Conozco estas convenciones, pero en realidad no dicen cómo se debe componer el nombre del artefacto (no hay convenciones de nomenclatura JAR) y qué hacer si fuera lo mismo que el ID de grupo: no he visto un solo POM donde ese es el caso
Noarth
@Noarth 1. El nombre del artefacto queda a su discreción (pero el uso de guiones en el nombre es una práctica común). 2. Estás buscando una "regla" absoluta que no existe (¿qué pasa si tu increíble marco interno está formado por varios módulos?). Véanse, por ejemplo, los artefactos Spring, Maven, Hibernate, etc.
Pascal Thivent
No, no, no tengo ningún módulo, solo proyectos simples. De hecho, no tenemos un proyecto llamado "marco
interno
11
¿Qué hay de package? ¿Cuál es la diferencia con groupId?
KonstantinK
1
¿Se permite que el artifactId tenga números?
theonlygusti
100

Considere lo siguiente para construir la primera aplicación básica de Maven :

groupId

  • com.companyname.project

artifactId

  • proyecto

version

  • 0.0.1
Manwal
fuente
Como trabajo por contrato, ¿debo usar com.my.company.projectcomo groupIdo com.client.company.project?
Giacomo Alzetta
@GiacomoAlzetta puedes usar cualquiera de los formatos de formiato que mejor te convenga. Algunos ejemplos 'com.companyName.hirePortal' u 'org.compnayName.hirePortal'.
Manwal
3
groupId debería ser com.companyname no com.companyname.project
Kamil Nekanowicz
1

Sin embargo, no estoy de acuerdo con la definición oficial de Guía para las convenciones de nomenclatura en groupId, artifactId y la versión que propone que groupId debe comenzar con un nombre de dominio invertido que usted controle.

comsignifica que este proyecto pertenece a una empresa, y orgsignifica que este proyecto pertenece a una organización social. Estos están bien, pero para aquellos dominios extraños como xxx.tv, xxx.uk, xxx.cn, no tiene sentido nombrar el groupId que comenzó con "tv", "cn.", El groupId debería entregar la información básica del proyecto en lugar del dominio.

Tommy.Tang
fuente
2
Esta convención impide que los desarrolladores utilicen maven debido a que debe poseer un dominio antes de implementar sus artefactos en el repositorio central de maven. Es ridículo. Poseer un dominio podría ser un costo considerable año tras año.
Tommy.Tang
1
No hay ningún requisito para poseer un registro para ese nombre de dominio. El único requisito es que su Id de grupo, que será el nombre de su paquete Java, no entre en conflicto con ningún otro nombre cuando se implemente. Esta convención ciertamente no impide que los desarrolladores usen Maven.
Basil Bourque
Una buena práctica es derivar nombres de paquetes de la URL del repositorio. Si está utilizando GitHub, se llama a su cuenta y se llama a myusersu repositorio myrepo, simplemente use el nombre del paquete com.github.myuser.myrepo. Eso es gratis y sigue siendo único.
fxnn
-14

Considere esto para obtener un archivo jar completamente único:

  • GroupID - com.companyname.project
  • ArtifactId - com-companyname-project
  • Paquete: com.companyname.project
descifrador
fuente