2009-07-09 10 views
18

Vi this question y me motivó a buscar nuevamente (sin éxito) en las configuraciones de Maven una forma alternativa de declarar la configuración para que se adjunte a la configuración del POM padre en lugar de anularla. En un Maven POM, si la configuración declara los mismos elementos que en el elemento primario, anula la configuración de los elementos principales. Como la respuesta aceptada a la otra pregunta dice, , este es el comportamiento esperado.Aumento en lugar de anular la configuración de Maven

Pero este no es siempre el comportamiento deseado. ¿Debería haber/hay medios en Maven para agregar a la configuración en lugar de anularla?

Por ejemplo: - ¿Ofrece la capacidad de declarar los elementos de la configuración definitiva, para que los niños puedan agregarlos pero no reemplazarlos? - Permitir configuración hijo a declarar elemento como una adición, por lo que se fusiona con el padre


Un buen ejemplo de cuando el comportamiento de anulación no siempre es deseable es para el elemento aspectLibraries de la aspectj-experto-plugin .

En mi POM principal, defino una configuración para el complemento aspectj que declara que una jarra de rastreo debe usarse como una biblioteca aspectLibrary.

<plugin> 
    <groupId>org.codehaus.mojo</groupId> 
    <artifactId>aspectj-maven-plugin</artifactId> 
    <executions> 
    <execution> 
    <id>compile_with_aspectj</id> 
     <goals> 
     <goal>compile</goal> 
     </goals> 
    </execution> 
    </executions> 
    <configuration> 
    <aspectLibraries> 
     <aspectLibrary> 
     <groupId>name.seller.rich</groupId> 
     <artifactId>tracing</artifactId> 
     </aspectLibrary> 
    </aspectLibraries> 
    </configuration> 
    <dependencies> 
    <dependency> 
     <groupId>aspectj</groupId> 
     <artifactId>aspectjtools</artifactId> 
     <version>1.5.3</version> 
    </dependency> 
    </dependencies> 
</plugin> 

Esto es heredado por todos los proyectos secundarios y obtengo el seguimiento en todos los proyectos, lo cual es bueno. Sin embargo, si defino otra aspectLibrary en un POM hijo, reemplaza mi configuración de rastreo.

Nota Tengo una solución a este problema en particular, estoy interesado en el caso general y las implicaciones para Maven.

La respuesta simple sería redeclarar la configuración para el jar de seguimiento en el POM hijo así como en el nuevo jar, pero esto tiene implicaciones de mantenimiento y si deseo declarar la configuración de rastreo en un perfil para que pueda ser deshabilitado si es necesario (lo cual hago), luego necesito volver a implementar el perfil en el niño.

La declaración de dependencia en la muestra anterior se combina con otras declaraciones de dependencia en el elemento primario y en otro lugar. Sé que las dependencias son un caso especial, pero muestra que es factible implementarlo.

Respuesta

21

Esto fue explicado en un blog post por Sonatype.

En el pom padre, especifique

<configuration> 
    <aspectLibraries combine.children="append"> 
    <aspectLibrary> 
     <groupId>name.seller.rich</groupId> 
     <artifactId>tracing</artifactId> 
    </aspectLibrary> 
    </aspectLibraries> 
</configuration> 

En general, los elementos de configuración de niños harán caso omiso de los especificados en la matriz cualquier complemento dado. Esto mantiene las cosas simples por defecto: un niño totalmente configurado usaría exactamente la configuración en su pom. Sin embargo, el padre puede exigir que las listas se extiendan en lugar de reemplazarse utilizando la configuración combine.children = "append" en los elementos de configuración deseados.

+2

Gracias es una gran ayuda Zac. Puede valer la pena aclarar su respuesta para mostrar que se trata de una característica genérica en todas las listas de configuración, no particular de aspectLibraries –

+1

actualizada según lo sugerido. Si este comportamiento cambia en futuras versiones de Maven, es de esperar que los que estén al tanto actualizarán las preguntas frecuentes del usuario maven. –

1

Necesito probar esto, así que permítanme volver sobre esto, pero creo que la forma correcta de hacerlo es usar properties, como se indica en here. En su caso, el código sería como sigue:

<properties> 
    <aspect.library.groupId>name.seller.rich</aspect.library.groupId> 
    <aspect.library.artifactId>tracing</aspect.library.artifactId> 
</properties> 

<plugin> 
    <groupId>org.codehaus.mojo</groupId> 
    <artifactId>aspectj-maven-plugin</artifactId> 
    <executions> 
    <execution> 
    <id>compile_with_aspectj</id> 
     <goals> 
     <goal>compile</goal> 
     </goals> 
    </execution> 
    </executions> 
    <configuration> 
    <aspectLibraries> 
     <aspectLibrary> 
     <groupId>${aspect.library.groupId}</groupId> 
     <artifactId>${aspect.library.artifactId}</artifactId> 
     </aspectLibrary> 
    </aspectLibraries> 
    </configuration> 
    <dependencies> 
    <dependency> 
     <groupId>aspectj</groupId> 
     <artifactId>aspectjtools</artifactId> 
     <version>1.5.3</version> 
    </dependency> 
    </dependencies> 
</plugin> 

Luego, en el niño que sería capaz de cambiar esas propiedades, y el padre le conteste automáticamente a los nuevos valores:

<properties> 
    <aspect.library.groupId>name.seller.rich</aspect.library.groupId> 
    <aspect.library.artifactId>something-else</aspect.library.artifactId> 
</properties> 

Creo Sin embargo, es posible que esté solicitando la posibilidad de agregar configuración, para tener un nodo adicional en la configuración de su hijo en la parte superior de la especificada en su elemento primario. Para ese caso, no puedo pensar en una solución obvia.

Cuestiones relacionadas