maven 2 - Maven2-problema con el pluginManagement y la relación padre-hijo

maven-2 (4)

Gestión de plugins: es un elemento que se ve a lo largo de complementos laterales. La administración de complementos contiene elementos de complementos de la misma manera, excepto que en lugar de configurar la información de complementos para esta construcción de proyecto en particular, está diseñada para configurar las construcciones de proyectos que se heredan de esta. Sin embargo, esto solo configura los complementos a los que realmente se hace referencia dentro del elemento complementos en los elementos secundarios. Los niños tienen todo el derecho de anular las definiciones de administración de plugins.

Ahora: si tengo esto en mi padre POM

y ejecuto mvn help: Effective-pom en el proyecto principal, obtengo lo que quiero, es decir, la parte de complementos directamente debajo de la compilación (la que hace el trabajo) permanece vacía.

Ahora si hago lo siguiente:

<build> <pluginManagement> <plugins> <plugin> <artifactId>maven-dependency-plugin</artifactId> <version>2.0</version> <executions> Some stuff for the children </execution> </executions> </plugin> </plugins> </pluginManagement> <plugins> <plugin> <artifactId>maven-compiler-plugin</artifactId> <version>2.0.2</version> <inherited>true</inherited> <configuration> <source>1.6</source> <target>1.6</target> </configuration> </plugin> </plugins> </build>

mvn help: Effective-pom Vuelvo a obtener justo lo que quiero, los complementos contienen solo lo que se declara y la sección de administración de complementos se ignora.

PERO cambiando con lo siguiente

<build> <pluginManagement> <plugins> <plugin> <artifactId>maven-dependency-plugin</artifactId> <version>2.0</version> <executions> Some stuff for the children </execution> </executions> </plugin> </plugins> </pluginManagement> <plugins> <plugin> <artifactId>maven-dependency-plugin</artifactId> <version>2.0</version> <inherited>false</inherited>  <executions> some stuff for adults only </execution> </executions> </plugin> </plugins> </build>

y ejecutando mvn help: efectivo-pom las cosas de la sección de administración de plugin se agrega encima de lo que ya está declarado. como tal :

<build> <pluginManagement> ... </pluginManagement> <plugins> <plugin> <artifactId>maven-dependency-plugin</artifactId> <version>2.0</version> <inherited>false</inherited>  <executions> Some stuff for the children </execution> <executions> some stuff for adults only </execution> </executions> </plugin> </plugins> </build>

¿Hay alguna manera de excluir la parte para niños de la sección del padre pom? En efecto, lo que quiero es que la administración del complemento se comporte exactamente como indica la documentación, es decir, quiero que se aplique solo para niños, pero no para el proyecto en el que se declara.

Como corolario, ¿hay alguna manera de anular las partes del administrador de complementos declarando el complemento en la sección de compilación normal de un proyecto? Lo que sea que intente, consigo que la sección se agregue a las ejecuciones, pero no puedo anular una que ya existe.

EDITAR:

Nunca encontré una solución aceptable para esto y, como tal, el problema sigue abierto. La solución más cercana se ofreció a continuación y actualmente es la solución aceptada para esta pregunta hasta que surja algo mejor. En este momento hay tres formas de lograr el resultado deseado (modular el comportamiento del complemento en función de la ubicación de la jerarquía de herencia de la POM actual):

1: el uso de perfiles funcionará, pero debe tener cuidado de que los perfiles no se hereden, lo cual es algo contrario a la intuición. Se aplican (si están activadas) al POM donde se declara y luego este POM generado se propaga hacia abajo. Como tal, la única forma de activar el perfil para POM hijo es específicamente en la línea de comandos (al menos no encontré otra forma). La propiedad, el archivo y otros medios de activación no activan el POM porque el activador no está en el POM donde se declara el perfil.

2 - (esto es lo que terminé haciendo) Declare el complemento como no heredado en el padre y vuelva a declarar (copiar y pegar) el tidbit en cada niño donde se desee. No es ideal pero es simple y funciona.

3 - Dividir la naturaleza de agregación y la naturaleza principal del POM principal. Luego, dado que la parte que solo se aplica a la matriz está en un proyecto diferente, ahora es posible usar pluginManagement como se pretendía en primer lugar. Sin embargo, esto significa que se debe crear un nuevo proyecto artificial que no contribuya al producto final, sino que solo sirva al sistema can. Este es un caso claro de sangrado conceptual. Además, esto solo se aplica a mi específico y es difícil de generalizar, así que abandoné los esfuerzos para intentar que esto funcionara a favor del parche de cortar y pegar no más bonito pero más contenido que se describe en 2.

Si alguien que se encuentra con esta pregunta tiene una solución mejor, ya sea por mi falta de conocimiento de Maven o porque la herramienta ha evolucionado para permitir esto, publique la solución aquí para futuras referencias.

Gracias por toda tu ayuda :-)

Agregar la configuración del complemento a la administración del complemento significa que esta configuración se usará si se declara el complemento, pero aún debe declarar el complemento en la sección de compilación de cualquier POM que quiera usarlo.

La parte clave que explica esto de la sección que citó es:

Sin embargo, esto solo configura los complementos a los que realmente se hace referencia dentro del elemento complementos en los elementos secundarios

Por lo tanto, si hace esto en el elemento secundario, se aplicará la configuración del elemento principal:

<build> <plugins> <plugin> <artifactId>maven-dependency-plugin</artifactId> </plugin> </plugins> </build>

Actualización: Para responder a la pregunta real, el contenido de la sección de administración de plugin siempre se fusiona con cualquier declaración de plugin. Para evitar que el padre haga esto, puede definir la sección de administración de complementos dentro de un perfil y activar ese perfil en proyectos secundarios pero no el padre. Los proyectos secundarios tendrían que declarar ese perfil.

Por ejemplo:

<profiles> <profile> <id>for-children</id> <build> <pluginManagement> <plugins> <plugin> <artifactId>maven-dependency-plugin</artifactId> <version>2.0</version> <executions>  </executions> </plugin> </plugins> </pluginManagement> </build> </profile> </profiles> <build> <plugins> <plugin> <artifactId>maven-dependency-plugin</artifactId> <version>2.0</version> <inherited>false</inherited>   </executions> </plugin> </plugins> </build>

Debe asignar una ID a la ejecución para que Maven sepa cuáles se sobrescriben y cuáles son independientes.

En el pom principal, debe configurar las ejecuciones con <goals> declarados pero no declarar <phase> . Luego en el niño pom declararás:

<plugin> <artifactId>some-plugin</artifactId> <executions> <execution> <id>execution-id</id> <phase>partcular-phase</phase> </execution> </executions> </plugin>

El complemento no se ejecutará hasta que defina una fase en el pom secundario. Por lo tanto, deberá vincular explícitamente las ejecuciones a las fases en cada pom secundario (o en la mitad de la jerarquía), pero no necesitará copiar y pegar la configuración de estas ejecuciones.

Tenga en cuenta que muchos complementos tienen Fase predeterminada, por ejemplo, el complemento de Enforcer está obligado a validate de forma predeterminada. Incluso si no vincula explícitamente el complemento a una fase, se vinculará de todos modos y, por lo tanto, se ejecutará el complemento. Para superar esto, use la fase no existente en su padre:

<execution> <id>execution-id</id> <goals><goal>some-goal</goal></goals> <phase>none</phase> </execution>

Siempre solía pensar que un POM secundario puede heredar una definición de complemento de la sección de administración de complementos de su padre y especificar solo las ejecuciones que desea ejecutar desde ese complemento al hacer referencia a ellas por ID y vincular la ejecución a una fase . Siempre que la definición principal esté en administración de complementos (y no directamente en complementos) y no esté vinculada a una fase, solo la ejecución específica (con ID) se ejecutará en esa fase.

Después de leer lo anterior y de mi propio problema actual, parece que eso no es cierto: parece que un POM secundario heredará toda la configuración del complemento, incluidas todas las ejecuciones. En términos de ejecuciones, lo único que puede hacer el niño es anular valores específicos, no puede elegir qué ejecuciones ejecutar y cuáles no.

¿Es esto un error? ¿De qué sirve poder vincular cada ejecución a una fase (o no), si se ejecutan todas las ejecuciones? Solo lo he visto con maven-dependency-plugin: unpack (enlazado a la fase del paquete ), pero con otros plugins podría haber tenido suerte ...

Maldita sea.