2009-10-22 15 views
13

Sto usando Maven e il suo plug-in di assemblaggio per costruire un pacchetto di distribuzione del mio progetto come questo:Come posso unire file di risorse in un assieme Maven?

  • un progetto assembla un runtime di base (sulla base di Felix), con le directory ei fasci appropriati, in uno ZIP file.
  • librerie di terze parti sono raccolte in un progetto ciascuna e convertite in pacchetti OSGi o, se sono già compatibili con OSGi, vengono semplicemente copiate
  • il mio progetto è composto da diversi moduli incorporati in bundle OSGi .

Ora, sto aggiungendo un altro progetto che decomprime lo ZIP, rilascia tutti gli altri JAR nelle directory corrette e lo ricompone per la distribuzione. Ora, i miei bundle potrebbero contenere file di configurazione che voglio unire, piuttosto che sostituire, quelli con nome identico nell'assieme di runtime. Come lo faccio?

I file sono di testo semplice (file di proprietà), ma in seguito potrebbe verificarsi una situazione simile con i file XML.

+0

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"? –

+0

@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. –

+0

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). –

risposta

6

Non so di una soluzione robusta a questo problema. Ma un po 'di guardarsi intorno dimostra che qualcuno ha created a plugin per unire i file delle proprietà. A giudicare dall'aspetto, è necessario dirgli quali file si uniscono, il che è una buona cosa in quanto non si desidera che questo venga applicato con pigrizia.

Supponendo di aver utilizzato dependency-unpack per decomprimere lo zip in una posizione nota, si tratterebbe di configurare il plug-in per unire ogni coppia di file delle proprietà e specificare la posizione di destinazione appropriata.

È possibile estendere il plug-in per gestire XML utilizzando qualcosa come xmlmerge da EL4J, come descritto in this Javaworld article.

+0

Fantastico, esamineremo quello. –

+0

Il plugin sembra funzionare davvero alla grande! –

+0

contento che funzioni, potrebbe tornare utile anche per me –

1

Ive ha anche creato un plugin per i file di unione, nel mio caso lo uso per unire file SQL di vari progetti in un unico file SQL di installazione che può creare tutti gli schemi/tabelle/dati statici ecc per le nostre app in un singolo file, http://croche.googlecode.com/svn/docs/maven-merge-files-plugin/0.1/usage.html

+0

Perché vedo http://croche.googlecode.com/svn/docs/maven-merge-files-plugin/0.4/usage.html come testo normale e non HTML? – xmedeko

20

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

+2

Risposta stupenda; Non sono riuscito a trovare questo correttamente documentato altrove. – ctrueden

+0

Tutto ciò solo per specificare 'metaInf-services'? Non ho bisogno o voglio un file 'descriptor.xml'. C'è un modo per indicare semplicemente il gestore 'metaInf-services' nella' 'nel POM> –

0

https://github.com/rob19780114/merge-maven-plugin (disponibile su centrale Maven) sembra anche per fare il lavoro. Vedi sotto per un esempio di configurazione

<plugin> 
    <groupId>org.zcore.maven</groupId> 
    <artifactId>merge-maven-plugin</artifactId> 
    <version>0.0.3</version> 
    <executions> 
     <execution> 
      <id>merge</id> 
      <phase>generate-resources</phase> 
      <goals> 
       <goal>merge</goal> 
      </goals> 
      <configuration> 
       <mergers> 
       <merger> 
        <target>${build.outputDirectory}/output-file-1</target> 
        <sources> 
        <source>src/main/resources/file1</source> 
        <source>src/main/resources/file2</source> 
        </sources> 
       </merger> 
       <merger> 
        <target>${build.outputDirectory}/output-file-2</target> 
        <sources> 
        <source>src/main/resources/file3</source> 
        <source>src/main/resources/file4</source> 
        </sources> 
       </merger> 
       </mergers> 
      </configuration> 
     </execution> 
    </executions> 

Problemi correlati