maven - central - pom.xml que es

Convenciones de nomenclatura de Maven para proyectos de módulos múltiples jerárquicos (3)

En días anteriores con maven seguí la siguiente estructura que usted ha descrito:

appname +--- appname-module1 +--- appname-module2 +--- appname-module2-chhild1 +--- appname-module2-chhild2 +--- appname-module3

Pero esto se volverá ridículo si consigues más niveles.

Así que decidí cambiar de opinión y ahora estoy usando cosas como:

appname +--- module1 +--- module2 +--- chhild1 +--- subchild1 +--- chhild2 +--- module3

Lo único que cambio a través de los niveles es el groupId ...

appname (groupId: com.soebes.appname) +--- module1 (groupId: com.soebes.appname.module1) +--- module2 (groupId: com.soebes.appname.module2) +--- chhild1 (groupId: com.soebes.appname.module1.child1) +--- chhild2 (groupId: com.soebes.appname.module1.child2) +--- module3 (groupId: com.soebes.appname.module3)

Tengo una pregunta sobre las convenciones de nomenclatura de Maven (groupId, artifactId y nombres de directorio) en un proyecto de módulo múltiple con una estructura de directorio jerárquica.

Investigación

Antes de preguntar, revisé otra página web sobre este tema y lo que borré por mi cuenta:

Posible duplicación de mi pregunta, pero no cubre los niveles de jerarquía múltiple.
El nombre del directorio del proyecto debe coincidir con artificatId .
Guía de convenciones de nombres proporcionan ejemplos:
- 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 del nombre del paquete (por ejemplo, org.apache.maven, org.apache.commons, org.apache.maven.plugins)
- artifactId Si lo creó, puede elegir el nombre que desee con letras minúsculas y sin símbolos extraños. (por ejemplo, maven, commons-math)

Esto es bastante sencillo y lo entiendo, pero hay algunas cosas que aún no están claras.

Los ejemplos de artefactos mencionados en las convenciones se pueden aplicar solo al módulo de jerarquía de un nivel.

Ejemplos

Revisé los repositorios de maven y extraje algunos ejemplos:

Spring usa principalmente nombres: spring-core, spring-context, spring-context-support. Todos los módulos independientes son una jerarquía de un nivel y un prefijo de resorte para la eficiencia de búsqueda. No hay problemas, ya que la jerarquía no es tan profunda.

Los nombres Apache CXF son bastante poco convencionales para Apache. Los artefactos son módulos independientes con hasta 5 artefactos diferentes posibles en nombres, por ejemplo. cxf-tools-wsdlto-databinding-jaxb.

Hay muchos artefactos (cxf-rt-databinding-jaxb, cxf-rt-databinding-aegis, cxf-rt-databinding-xmlbeans, cxf-rt-databinding-sdo) que se pueden agrupar en proyectos de varios módulos (cxf-rt -las encuadernaciones), pero no lo hicieron y por eso los nombres se convirtieron en espaguetis.

Finalmente, Maven Plugins es primero un proyecto de módulo múltiple (después de org.apache.maven) que tiene artefactos como: maven-compiler-plugin, maven-enforcer-plugin.

Hay bastantes ejemplos y todos siguen diferentes convenciones para nombrar artefactos (en consecuencia, directorios de proyectos).

Salir

Tomando las mejores prácticas de los ejemplos, revisemos los niveles de jerarquía.

La denominación de jerarquía de un nivel sería (

groupId: org.organization.project artifactId: project-portal ---. | project-portal-service | project-portal-plugins (continued on next diagram) | project-portal-util

(continuación) la jerarquía de dos niveles sería:

groupId: org.organization.project.plugins artifactId: project-portal-plugins ---. | project-sample-plugin | project-another-great-plugin | ???? (multiple module project)

¿Ves signos de interrogación? Eso es donde el

Preguntas

Seguí las convenciones de los ejemplos (ignorando el ejemplo de Espagueti Apache CXF):

Root - portal del proyecto (por ejemplo, spring-core, maven-core)
Los nombres de jerarquía de primer nivel se heredan de raíz: proyecto-portal-complementos (por ejemplo, spring-context-support).
Nombres de jerarquía de segundo nivel - project-sample-plugin (por ejemplo, maven-compiler-plugin).

Y ahora estamos atrapados en el tercer nivel, como en juegos antiguos sin guardias y puntos de control.

¿Es esta la correcta ruta de nombres de directorio tomada de los ejemplos de Maven para niveles de jerarquía más profundos?
¿Hay alguna convención o regla que sigas para admitir nombres simples de directorios y artefactos, evitando nombres de espagueti en niveles más profundos?
Si hay nombres simples, ¿groupId guardará los nombres de artefactos duplicados (lo que ocurrirá debido a la simplicidad) de las colisiones en el repositorio?
¿Qué hay de buscar y encontrar artefactos en la web / repositorios con nombres duplicados (debido a la simplicidad)?

No quiero ver en mi estructura de proyecto un módulo como project-portal-liferay-plugins-themes para los padres o, peor aún, project-portal-liferay-plugins-themes-white-puppy-wtf-name para niños.

Si pudiera aportar su opinión y la práctica ante cualquiera de las preguntas mencionadas y los posibles problemas, sería una gran ayuda no solo para mí, sino también para todos los que usen Maven. Gracias.

No creo que existan convenciones que especifiquen claramente cómo debe configurar su estructura de proyecto en este caso.

Por ejemplo, trataría de responder donde los artefactos terminan con su nombre y cuál es la posibilidad de encontrarse con un conflicto. Para un marco como Spring, tiene sentido tener el nombre del proyecto en el artifactId ("spring- *"), lo mismo es cierto para las bibliotecas comunes (aunque el "registro de los comunes" puede tener un nombre de riesgo).

Para un proyecto que se ejecuta de forma independiente, probablemente no sea necesario para hacer esto. Pero parece que usarás un portal de por vida donde habrá muchos tarros diferentes por lo que te recomendaría un prefijo para los artefactos. Pero no trataría de reconstruir la estructura del proyecto en función de artifactId. Entonces, "project-modulename" será un buen nombre de módulo. Dado que los archivos jar construirán el classpath y la estructura de dependencia se definió durante la compilación, esto no es un problema. Si necesita reconstruir el árbol de dependencias basándose en una lista de archivos jar: maven incluye información en META-INF (si utiliza el complemento de versión, que también recomiendo) para que pueda recuperar la información desde allí.

También recomendaría no anidar módulos a profundidad. Eclipse tiene algunos problemas con esto (IntelliJ no, Netbeans afaik también admite estructuras anidadas).

El módulo de portal principal no puede cambiar tan a menudo en comparación con los módulos de complemento. Por lo tanto, tiene sentido dividirlos en proyectos separados; esto también permitiría lanzar los proyectos por separado.

Para mí, es una buena práctica nombrar los módulos principales con el sufijo "-parent". Estos módulos rara vez se usan como dependencia y un "-parent" para una dependencia indica que algo es sospechoso. Como dijiste: el nombre de artifacId y del módulo debería ser el mismo. También recomendaría usar el artifactId como nombre en el pom. Algunos complementos no consideran las diferencias aquí y también Eclipse se comporta mejor si estos valores son todos iguales.

Es cierto que goupId y el artifactId a menudo contienen información duplicada (p. Ej., Partes de ella serán el nombre del proyecto). Si esto se hizo a propósito o sucedió en los últimos años ...? No lo sé, pero lo mantendría de esta manera. Los artefactos se identifican utilizando las coordenadas GAV (P) (groupId, artifactId, version, (packaging)). Si groupId o artifactId contienen el nombre del proyecto, los artefactos son más fáciles de encontrar si solo tiene uno de ellos.

Encontrar artefactos es fácil si está ejecutando un administrador de repositorios (como Nexus, Artifactory, Archiva). La búsqueda a menudo generará groupId / artifactId y así sucesivamente, por lo que una búsqueda de "util" le daría suficiente información para encontrar el artefacto que está buscando.

Espero que esto haya ayudado un poco :) saludos

wemu

Otro enfoque posible es mirar los grupos de funciones más que la jerarquía.

Supongamos que el proyecto B tiene aplicaciones web, complementos y bibliotecas principales, luego todos los módulos comparten la misma identificación de grupo (com.mycompany.b) y los artefactos se denominan respectivamente webapp - ???, plugin - ??? y núcleo - ???.

También usamos la convención -parent mencionada anteriormente: por lo tanto, el POM padre para todas las aplicaciones web se llama webapp-parent.pom.