2015-01-26 11 views
6

Sto riscontrando problemi nella creazione di un progetto maven. Ho l'obbligo di produrre file jar deterministici, che devono essere coerenti in modo binario tra diverse versioni e versioni, nel caso in cui non vi siano modifiche al codice sorgente tra queste versioni. Per lo scopo, ho usato this article per la guida.Allegare manualmente artefatto principale se compilato da maven-assembly-plugin

Sono riuscito a costruire i miei vasi e sono coerenti con le mie esigenze. Qui è la mia configurazione:

<plugin> 
    <artifactId>maven-antrun-plugin</artifactId> 
    <version>1.7</version> 
    <executions> 
     <execution> 
     <id>step-1-remove-timestamp</id> 
     <phase>prepare-package</phase> 
     <configuration> 
      <target> 
      <touch datetime="01/01/2015 00:10:00 am"> 
       <fileset dir="target/classes"/> 
       <fileset dir="src"/> 
      </touch> 
      </target> 
     </configuration> 
     <goals> 
      <goal>run</goal> 
     </goals> 
     </execution> 
     <execution> 
     <id>step-3-rename-assembly</id> 
     <phase>package</phase> 
     <configuration> 
      <target> 
      <copy file="${project.build.directory}/${project.build.finalName}-deterministic.zip" 
        tofile="${project.build.directory}/${project.build.finalName}.jar"/> 
      </target> 
     </configuration> 
     <goals> 
      <goal>run</goal> 
     </goals> 
     </execution> 
    </executions> 
    </plugin> 

    <plugin> 
    <artifactId>maven-assembly-plugin</artifactId> 
    <version>2.2.1</version> 
    <configuration> 
     <descriptors> 
     <descriptor>src/main/assembly/zip.xml</descriptor> 
     </descriptors> 
    </configuration> 
    <executions> 
     <execution> 
     <id>step-2-make-assembly</id> 
     <phase>prepare-package</phase> 
     <goals> 
      <goal>single</goal> 
     </goals> 
     </execution> 
    </executions> 
    </plugin> 

Nel codice sopra costruisco e confezionare il vaso come un lampo, quindi copiare la zip sul manufatto vaso previsto.
Il problema con quanto sopra, è che ancora eseguiamo lo maven-jar-plugin, quindi il contenitore assemblato manualmente viene sovrascritto da uno degli maven-jar-plugin. Non voglio usare questo barattolo, poiché non è coerente con le mie esigenze.

Così, ho disattivato l'esecuzione maven-jar-plugin, impostando esplicitamente di correre per una fase non valida, come qui di seguito: (visto che da other posts here)

<plugin> 
    <groupId>org.apache.maven.plugins</groupId> 
    <artifactId>maven-jar-plugin</artifactId> 
    <version>2.5</version> 
    <executions> 
     <execution> 
     <id>default-jar</id> 
     <phase>never</phase> 
     <configuration> 
      <finalName>unwanted</finalName> 
      <classifier>unwanted</classifier> 
     </configuration> 
     </execution> 
    </executions> 
    </plugin> 

Tutto sembra in ordine, fino a quando ho scoperto il mio vaso principale l'artefatto non viene mai installato nella directory .m2. Per correggere questo, ho aggiunto anche il maven-helper-plugin in modo che allego manualmente i manufatti che produco dal plugin assembler:

<plugin> 
    <groupId>org.codehaus.mojo</groupId> 
    <artifactId>build-helper-maven-plugin</artifactId> 
    <version>1.9.1</version> 
    <executions> 
     <execution> 
     <id>attach-instrumented-jar</id> 
     <phase>verify</phase> 
     <goals> 
      <goal>attach-artifact</goal> 
     </goals> 
     <configuration> 
      <artifacts> 
      <artifact> 
       <file>${project.build.directory}/${project.build.finalName}.jar</file> 
       <type>jar</type> 
      </artifact> 
      </artifacts> 
     </configuration> 
     </execution> 
    </executions> 
    </plugin> 

Questo porta ad un errore non sono in grado di risolvere:

[ERRORE] Impossibile eseguire l'obiettivo org.codehaus.mojo: build-helper-maven-plugin: 1.9.1: attach-artefatto (attach-instrumented-jar) sul progetto my-project: Execution attach-instrumented-jar dell'obiettivo org.codehaus. mojo: build-helper-maven-plugin: 1.9.1: attach-artefatto non riuscito: per artefatto {nome-completo-di-mio-progetto.jar}: Un artefatto collegato deve avere un ID diverso rispetto al suo artefatto principale corrispondente. -> [Guida 1]

C'è un modo per superare questo problema? Ho verificato la presenza di soluzioni e la maggior parte consiglia l'uso di classificatori, ma voglio installare l'artefatto principale come farebbe lo maven-jar-plugin. Altri software che stiamo sviluppando richiederanno la dipendenza standard del jar e vogliamo evitare di complicare la nostra configurazione introducendo i classificatori in modo irragionevole.

risposta

3

Dopo un po 'di tentativi e fallimenti mi è capitato di venire con una soluzione funzionante. Lo sto postando qui con la speranza di essere utile, o di avere problemi con me, dato che non sono molto fiducioso se questo è un approccio affidabile.

Quindi, l'errore che ha ricevuto

Un artefatto allegato deve avere un ID diverso rispetto al suo corrispondente manufatto principale.

significato per me che non posso installare manualmente "di nuovo" l'artefatto principale. Poiché tale artefatto non viene più prodotto dallo maven-jar-plugin, non viene mai pianificato per l'installazione anche se il file è presente (l'attività di copia antron produce un jar con lo stesso nome).

Sorprendentemente, aveva bisogno di un paio di piccoli trucchi per rendere di nuovo questo lavoro:

  1. Re-enabled la maven-jar-plugin come dovrebbe essere:

    <plugin> 
        <groupId>org.apache.maven.plugins</groupId> 
        <artifactId>maven-jar-plugin</artifactId> 
        <version>2.5</version> 
        <executions> 
        <execution> 
         <id>default-jar</id> 
         <phase>package</phase> 
        </execution> 
        </executions> 
    </plugin> 
    

    Questo produrrà il vaso di serie sulla package fase, e, soprattutto, rende Maven consapevole per essere installato durante la fase install.

  2. Modificare le attività di copia maven-antrun-plugin su sovrascrivere il barattolo già prodotto con lo zip deterministico. L'installazione è quasi identica come nella mia interrogazione, quindi sono solo aggiungendo le differenze:

    <plugin> 
        <artifactId>maven-antrun-plugin</artifactId> 
        <version>1.7</version> 
        <executions> 
        <execution>...</execution> 
        <execution> 
         <id>step-3-rename-assembly-and-sources</id> 
         <phase>package</phase> 
         <configuration> 
         <target> 
          <copy file="${project.build.directory}/${project.build.finalName}-deterministic.zip" 
           tofile="${project.build.directory}/${project.build.finalName}.jar" 
           overwrite="true"/> 
         </target> 
         </configuration> 
        </execution> 
         . . . 
        </executions> 
    </plugin> 
    

    L'operazione di copia ha ora overwrite="true" specificato. Inizialmente, l'operazione di copia sembrava ignorare i file nella destinazione, se già esistono, e ciò che è successo è che lo maven-jar-plugin aveva già prodotto l'artefatto jar predefinito quando si verificava la copia. Con questa opzione impostata, lo maven-antrun-plugin sostituisce ora il vaso precedente con quello deterministico e quest'ultimo diventa un oggetto della fase Maven install.

  3. rimosso la messa a punto dalla build-helper-maven-plugin, in modo che il vaso principale artefatto non viene copiata una seconda volta:

 

      <artifact> 
       <file>${project.build.directory}/${project.build.finalName}.jar</file> 
       <type>jar</type> 
      </artifact> 
 

Ecco, il jar corretto è installato nella directory .m2.

Problemi correlati