maven 2 - que - Convención de nombres para artefactos de Maven

mvn eclipse eclipse para que sirve

Question

Actualmente estamos tratando de mavenizar los proyectos existentes en nuestra empresa. Hemos ejecutado un POC y actualmente estamos documentando nuestros aprendizajes y pautas. He llegado a la siguiente convención de nomenclatura para los artefactos de Maven. Por favor comparte tus comentarios sobre el mismo.

Nota: en nuestra empresa, el nombre del proyecto es siempre único

Para un proyecto de varios niveles de maven de módulo.

Padre (pom)

• groupId: org.companyname.projectname
• artifactId: org.companyname.projectname
• versión: xxx

por ejemplo: org.companyname.projectname: org.companyname.projectname-1.0.0.pom

Módulos (tarro)

• groupId: org.companyname.projectname
• artifactId: org.companyname.projectname.modulename
• versión: xxx

por ejemplo: org.companyname.projectname: org.companyname.projectname.modulename-1.0.0.jar

Para un proyecto multinivel de varios niveles.

Padre (pom)

• groupId: org.companyname.projectname
• artifactId: org.companyname.projectname
• versión: xxx

por ejemplo: org.companyname.projectname: org.companyname.projectname-1.0.0.pom

Subparente (pom)

• groupId: org.companyname.projectname
• artifactId: org.companyname.projectname.subcategory
• versión: xxx

por ejemplo: org.comnombre_proyecto.nombre del proyecto: org.comnombre_proyecto.nombre del proyecto.subcategory-1.0.0.pom

Módulo (tarro)

• groupId: org.companyname.projectname
• artifactId: org.companyname.projectname.subcategory.modulename
• versión: xxx

por ejemplo: org.comnombre_proyecto.nombre del proyecto: org.comnombre_proyecto.nombre del proyecto.subcategory.modulename-1.0.0.jar

Answer 1

Usar un nombre no calificado para groupId que coincida con artifactId (por ejemplo, log4j ) es una práctica obsoleta que no se recomienda : es malo a nivel del sistema de archivos, genera un "desorden de repositorio", hace que sea más difícil encontrar artefactos cuando se navega en un repositorio ( incluso si la mayoría de la gente usa un motor de búsqueda hoy en día).

La recomendación es incluir su nombre de dominio en groupId y ciertamente no lo repetiría en artifactId (que yo sepa, Spring NO está haciendo eso , ¿excepto para los artefactos OSGI?).

Aquí está lo que yo uso:

Padre (pom)

• groupId: org.companyname.projectname
• artifactId: root
• versión: xxx

por ejemplo: org.companyname.projectname: root-1.0.0.pom

Subparente (pom)

• groupId: org.companyname.projectname
• artifactId: subcategoría-padre
• versión: xxx

por ejemplo: org.companyname.projectname: subcategory-parent-1.0.0.pom

Módulo (tarro)

• groupId: org.companyname.projectname
• artifactId: modulename
• versión: xxx

por ejemplo: org.companyname.projectname: modulename-1.0.0.jar

Y también uso las convenciones para el elemento <description> para tener una visión general limpia durante las construcciones del reactor. Aquí hay un ejemplo de un proyecto de mascota:

$ mvn compile [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Personal Sandbox - Samples - Parent POM [INFO] Personal Sandbox - Samples - EJB3 and Cargo Sample [INFO] Personal Sandbox - Tools - Parent POM [INFO] Personal Sandbox - Tools - Shared Verification Resources [INFO] Personal Sandbox - Samples - EJB3 and Cargo Sample - Services [INFO] Personal Sandbox - Samples - EJB3 and Cargo Sample - Functests [INFO] Sandbox Externals POM

Esto está fuertemente inspirado por la forma en que Vincent Massol organiza grandes construcciones como lo hizo con XWiki o Cargo.

Answer 2

En mi opinión, no es necesario que incluya org.companyname en el artifactId; simplemente está duplicando la información que ya está presente en groupId, lo que hace que los nombres de los artefactos sean más largos y menos legibles.

Actualización: Para su información, revisando las dependencias de nuestro proyecto, veo muchos ejemplos similares, por ejemplo

<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>

<groupId>org.codehaus.mojo</groupId>
<artifactId>jboss-maven-plugin</artifactId>

<groupId>net.sf.barcode4j</groupId>
<artifactId>barcode4j-fop-ext-0.20.5-complete</artifactId>

<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>

<groupId>opensymphony</groupId>
<artifactId>oscache</artifactId>

<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-libs</artifactId>

<groupId>javax.resource</groupId>
<artifactId>connector-api</artifactId>

<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>

<groupId>javax.transaction</groupId>
<artifactId>jta</artifactId>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>

Y luego hay muchos en los que los ID de grupo y artefacto tienen el mismo nombre no calificado, por ejemplo:

<groupId>log4j</groupId>
<artifactId>log4j</artifactId>

<groupId>velocity</groupId>
<artifactId>velocity</artifactId>

<groupId>fop</groupId>
<artifactId>fop</artifactId>

<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>

Pero no he visto ninguna con un ID de grupo completo y un ID de artefacto idéntico (que, por ejemplo, para Log4J sería org.apache.log4j:org.apache.log4j ).