java - tipos - ¿Cómo especificar la distribución de maven? ¿Toda la organización de gestión?

setlayout java

Question

Estoy tratando de descubrir cómo organizar muchos (alrededor de 50) proyectos maven2, para que puedan implementarse en un repositorio central de nexus. Al usar el mvn deploy , uno necesita especificar el objetivo en la etiqueta de DistributionManagement de la siguiente manera:

<distributionManagement>
<repository>
<id>nexus-site</id>
<url>http://central_nexus/server</url>
</repository>
</distributionManagement>

Ahora, no quiero que todos los pom.xml (de esos 50+) contengan este bloque una y otra vez. Mi primer sin embargo sería el archivo settings.xml , pero parece que no es posible (por diseño) definirlo allí. Entonces, la primera pregunta sería, ¿por qué es ese el caso? Si fuera posible, podría especificarlo en settings.xml en la distribución maven2, que podría distribuirse a todos los desarrolladores.

La única solución posible que encontré fue crear un proyecto maestro-pom para toda la organización, que contiene estas configuraciones, y hacer que todos los demás pom.xml dependan de este master-pom a través de <parent> etiqueta <parent> . Pero esto parece extraño en las compilaciones de varios módulos:

- master configuration POM (pm)
- Project 1 parent pom (p1 with module 1 and module 2 as modules)
- Project 1 module pom (with pm as parent)
- Project 2 module pom (with pm as parent)

Por lo general, leo en toda la documentación que los módulos poms deben usar el pom padre, no otro diferente. Pero después de leer el sitio web de maven sobre Intenitance v. Aggregation, está escrito que sí es posible.

Un problema que encontré fue con la generación del sitio maven, que parece tener problemas con esta configuración (los módulos no se vinculan correctamente si no tienen referencias directas).

Entonces, ¿es este un enfoque válido? ¿Alguna otra solución más obvia y más simple para el problema?

Answer 1

La mejor solución para esto es crear un proyecto de archivo pom padre simple (con el paquete ''pom'') genéricamente para todos los proyectos de su organización.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>your.company</groupId>
<artifactId>company-parent</artifactId>
<version>1.0.0-SNAPSHOT</version>
<packaging>pom</packaging>
<distributionManagement>
<repository>
<id>nexus-site</id>
<url>http://central_nexus/server</url>
</repository>
</distributionManagement>
</project>

Esto se puede construir, lanzar e implementar en su nexo local para que todos tengan acceso a su artefacto.

Ahora, para todos los proyectos que desee usar, simplemente incluya esta sección:

<parent>
<groupId>your.company</groupId>
<artifactId>company-parent</artifactId>
<version>1.0.0</version>
</parent>

Esta solución le permitirá agregar fácilmente otras cosas comunes a todos los proyectos de su empresa. Por ejemplo, si desea estandarizar su uso de JUnit a una versión específica, este sería el lugar perfecto para eso.

Si tiene proyectos que usan estructuras de múltiples módulos que tienen su propio elemento primario, Maven también admite encadenar herencia, por lo que es perfectamente aceptable hacer que el archivo principal pom del proyecto se refiera al archivo principal de la empresa y que los módulos secundarios del proyecto ni siquiera conozcan su padre de la compañía

Veo en su estructura de proyecto de ejemplo que está tratando de poner su proyecto principal en el mismo nivel que su agregador pom. Si su proyecto necesita su propio padre, el mejor enfoque que he encontrado es incluir el padre en el mismo nivel que el resto de los módulos y tener su archivo agregador pom.xml en la raíz de donde están todos los directorios de sus módulos.

- pom.xml (aggregator)
- project-parent
- project-module1
- project-module2

Lo que usted hace con esta estructura es incluir su módulo padre en el agregador y compilar todo con una ''instalación mvn'' desde el directorio raíz.

Usamos esta solución exacta en mi organización y ha resistido la prueba del tiempo y funcionó bastante bien para nosotros.