Espansione un po 'sulla risposta di Juergen per coloro che inciampano su questo - il containerDescriptorHandler
nel descrittore può assumere quattro valori (v2.3), questi sono metaInf-services
, file-aggregator
, plexus
, metaInf-spring
. È un po 'nascosto nel codice (trovato nel pacchetto org.apache.maven.plugin.assembly.filter
) ma è possibile aggregare i file di configurazione/proprietà.
Ecco un descrittore di esempio che aggrega i file di proprietà con nome META-INF/services
e situati in 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>
Il file-aggregator
possono contenere un'espressione regolare nella filePattern
per abbinare più file. Quanto segue corrisponderebbe a tutti i nomi di file 'action.properties'.
<filePattern>.+/action.properties</filePattern>
Il metaInf-services
e metaInf-spring
sono utilizzati per aggregare SPI e configurazione molla file rispettivamente mentre il conduttore plexus
si aggregano META-INF/plexus/components.xml
insieme.
Se è necessario qualcosa di più specializzato è possibile aggiungere il proprio gestore di configurazione implementando ContainerDescriptorHandler
e definendo il componente in META-INF/plexus/components.xml
. Puoi farlo creando un progetto upstream che ha una dipendenza da maven-assembly-plugin
e contiene il tuo gestore personalizzato. Potrebbe essere possibile farlo nello stesso progetto che stai assemblando ma non l'ho provato. Le implementazioni dei gestori sono disponibili nel pacchetto org.apache.maven.plugin.assembly.filter.*
del codice sorgente dell'assembly.
CustomHandler.java
package com.mycompany;
import org.apache.maven.plugin.assembly.filter.ContainerDescriptorHandler;
public class CustomHandler implements ContainerDescriptorHandler {
// body not shown
}
indicare la componente /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>
Infine si aggiunge questo come una dipendenza del plugin di assemblaggio in il progetto che desideri assemblare
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>
e definire la handlerName nel descrittore
descriptor.xml
...
<containerDescriptorHandler>
<handlerName>custom-handler</handlerName>
</containerDescriptorHandler>
...
Il maven-shade-plugin possono anche creare 'uber-giare' e ha alcune trasformazioni di risorse per la gestione di XML, licenze e manifest.
J
Io non so tutto ciò che può fare questo. Detto questo, non sono molto abituato all'OSGI. Tuttavia, si tratta di un caso d'uso "regolare"? –
@Pascal - Questo non è specifico per OSGi, davvero. Non sono sicuro di quanto sia regolare, ma potrei immaginare che se volessi unire i bundle WAR o OSGi, potrei voler unire rispettivamente i file web.xml o MANIFEST.MF. Sono sicuro che ci sono altri compiti dello stesso tipo, ma forse c'è un approccio completamente diverso a questo. –
Perché unire i bundle OSGI? Sono un grande noob con OSGI ma non sono unità indipendenti? Per WARs, è un po 'più chiaro ma posso pensare a molti problemi con un'unione (es. Cosa succede se entrambe le guerre hanno un 'index.jsp', e se entrambi fanno affidamento sulla stessa lib ma con versioni differenti, ecc.) E li considererei piuttosto come unità indipendenti. Patchare un 'web.xml' sembra più" realista "(e può essere utile, ad esempio in un contesto di test, il carico ha un obiettivo per questo). –