sirve que para mvn hace estructura ejemplo descargar maven-2 naming-conventions

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



mvn eclipse eclipse para que sirve (2)

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

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.

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 ).