Expandiendo un poco la respuesta de Juergen para aquellos que tropiezan con esto, el containerDescriptorHandler
en el descriptor puede tomar cuatro valores (v2.3), estos son metaInf-services
, file-aggregator
, plexus
, metaInf-spring
. Está un poco enterrado en el código (se encuentra en el paquete org.apache.maven.plugin.assembly.filter
), pero es posible agregar archivos de configuración/propiedades.
Aquí hay un descriptor de ejemplo que agrega los archivos de propiedad META-INF/services
y ubicados en com.mycompany.actions
.
descriptor.xml
<assembly>
...
<containerDescriptorHandlers>
<containerDescriptorHandler>
<handlerName>metaInf-services</handlerName>
</containerDescriptorHandler>
<containerDescriptorHandler>
<handlerName>file-aggregator</handlerName>
<configuration>
<filePattern>com/mycompany/actions/action.properties</filePattern>
<outputPath>com/mycompany/actions/action.properties</outputPath>
</configuration>
</containerDescriptorHandler>
</containerDescriptorHandlers>
....
</assembly>
El file-aggregator
puede contener una expresión regular en la filePattern
para que coincida con varios archivos. Lo siguiente coincidiría con todos los nombres de archivos 'action.properties'.
<filePattern>.+/action.properties</filePattern>
El metaInf-services
y metaInf-spring
se utilizan para la agregación y la configuración de la primavera SPI archivos, respectivamente, mientras que el manejador se plexus
agregar META-INF/plexus/components.xml
juntos.
Si necesita algo más especializado, puede agregar su propio controlador de configuración implementando ContainerDescriptorHandler
y definiendo el componente en META-INF/plexus/components.xml
. Puede hacerlo creando un proyecto ascendente que tenga una dependencia en maven-assembly-plugin
y contenga su controlador personalizado. Es posible hacer esto en el mismo proyecto que estás armando, pero no lo intenté. Las implementaciones de los controladores se pueden encontrar en el paquete org.apache.maven.plugin.assembly.filter.*
del código fuente del ensamblaje.
CustomHandler.java
package com.mycompany;
import org.apache.maven.plugin.assembly.filter.ContainerDescriptorHandler;
public class CustomHandler implements ContainerDescriptorHandler {
// body not shown
}
entonces definir el componente en /src/main/resources/META-INF/plexus/components.xml
components.xml
<?xml version='1.0' encoding='UTF-8'?>
<component-set>
<components>
<component>
<role>org.apache.maven.plugin.assembly.filter.ContainerDescriptorHandler</role>
<role-hint>custom-handler</role-hint>
<implementation>com.mycompany.CustomHandler</implementation>
<instantiation-strategy>per-lookup</instantiation-strategy>
</component>
</components>
</component-set>
Finalmente se agrega esto como una dependencia en el plug-in de montaje en el proyecto que desea ensamblar
pom.xml
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.2.1</version>
<configuration>
<descriptors>
<descriptor>...</descriptor>
</descriptors>
</configuration>
<dependencies>
<dependency>
<groupId>com.mycompany</groupId>
<artifactId>sample-handler</artifactId>
<version>1.0</version>
</dependency>
</dependencies>
</plugin>
y definir el handlerName en el descriptor de
descriptor.xml
...
<containerDescriptorHandler>
<handlerName>custom-handler</handlerName>
</containerDescriptorHandler>
...
El maven-shade-plugin también puede crear 'uber-tarros' y tiene algunas transformaciones de recursos para manejar XML, licencias y manifiestos.
J
No sé nada que pueda hacer esto. Dicho esto, no estoy muy acostumbrado a OSGI. Sin embargo, ¿es este un caso de uso "regular"? –
@Pascal - Esto no es específico de OSGi, realmente. No estoy seguro de cuán regular es esto, pero podría imaginar que si quería fusionar WARs u OSGi bundles, me gustaría fusionar archivos web.xml o MANIFEST.MF, respectivamente. Estoy seguro de que hay otras tareas del mismo tipo, pero tal vez haya un enfoque completamente diferente de esto. –
¿Por qué fusionar paquetes OSGI? Soy un gran novato con OSGI, pero ¿no son unidades independientes? Para las WAR, es un poco más claro, pero puedo pensar en muchos problemas con una fusión (por ejemplo, ¿qué pasa si ambas guerras tienen un 'index.jsp', qué pasa si ambas dependen de la misma lib pero con diferentes versiones, etc.) y preferiría considerarlos como unidades independientes también. Parchar un 'web.xml' parece más" realista "(y puede ser útil, por ejemplo, en un contexto de prueba, la carga tiene un objetivo para eso). –