maven 2 - pom - Maven artefacto y nombrar groupId

pom maven (5)

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

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

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

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

Finalmente, tengo que elegir un artifactId , actualmente fui para teatimer . Pero cuando miro otros proyectos de Maven, usan guiones para dividir palabras en artifactId , como este: tea-timer . Pero se ve raro cuando se concatena al 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 (?)

Considera esto para obtener un archivo jar completamente único:

GroupID - com.companyname.project
ArtifactId - com-companyname-project
Paquete - com.companyname.project

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

groupId

com.companyname.project

artifactId

proyecto

version

0.0.1

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

Guía para las convenciones de nombres en groupId, artifactId y versión
groupId identificará su proyecto de forma única en todos los proyectos, por lo que debemos aplicar un esquema de nombres. Tiene que seguir las reglas de nombre del paquete, lo que significa que debe ser al menos como un nombre de dominio que usted controla, y puede crear tantos subgrupos como desee. Mire más información sobre nombres de paquetes .
p.ej. org.apache.maven , org.apache.commons
Una buena manera de determinar la granularidad de groupId es usar la estructura del proyecto. Es decir, si el proyecto actual es un proyecto de múltiples módulos, debe agregar un nuevo identificador al groupId del padre.
p.ej. org.apache.maven , org.apache.maven.plugins , org.apache.maven.reporting
artifactId es 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 frasco de un tercero, debe tomar el nombre del frasco tal como se distribuye.
p.ej. maven , commons-math
version si la distribuye, entonces puede elegir cualquier versión típica con números y puntos (1.0, 1.1, 1.0.1, ...). No utilice fechas, ya que generalmente se asocian con compilaciones SNAPSHOT (nocturnas). 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

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

com significa que este proyecto pertenece a una empresa, y org significa que este proyecto pertenece a una organización social. Estos están bien, pero para los dominios extraños como xxx.tv, xxx.uk, xxx.cn, no tiene sentido nombrar groupId que comenzó con "tv.", "Cn.", GroupId debería proporcionar la información básica. del proyecto en lugar del dominio.

Su convención parece ser razonable. Si estuviera buscando su marco en el repositorio de Maven, buscaría awesome-inhouse-framework-xyjar en el directorio de grupo com.mycompany.awesomeinhouseframework . Y lo encontraría allí de acuerdo a su convención.

Dos reglas simples funcionan para mí:

paquetes de dominio-inverso para groupId (ya que son bastante únicos) con todas las docs.oracle.com/javase/tutorial/java/package/namingpkgs.html respecto a los nombres de paquetes Java
nombre del proyecto como artifactId (teniendo en cuenta que debe ser compatible con jar-name, es decir, que no contenga caracteres que quizás no sean válidos para un nombre de archivo o que parezcan raros)