2015-01-26 10 views
6

Ich habe Probleme beim Aufbau eines Maven-Projekts. Ich habe die Anforderung, deterministische JAR-Dateien zu erzeugen, die in verschiedenen Builds und Versionen binärkonsistent sein müssen, falls zwischen diesen Builds keine Quellcodeänderungen auftreten. Zu diesem Zweck habe ich this article zur Orientierung verwendet.Manuelles Anhängen des Hauptartefakts, wenn es von maven-assembly-plugin erstellt wird

Ich habe erfolgreich geschafft, meine Gläser zu bauen, und sie sind konsistent, um meine Anforderungen zu erfüllen. Hier ist meine Konfiguration:

<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> 

In dem obigen Code, den ich bauen und das Glas als Zip-Paket, dann kopieren Sie die Zip über die erwartete jar Artefakt.
Das Problem mit dem oben genannten ist, dass maven immer noch die maven-jar-plugin ausführt, so dass das manuell zusammengebaute Glas durch das der maven-jar-plugin überschrieben wird. Ich möchte dieses Glas nicht verwenden, da es nicht meinen Anforderungen entspricht.

Also, ich habe die maven-jar-plugin Ausführung deaktiviert, indem sie explizit Einstellung für eine ungültige Phase zu laufen, wie folgt: (sah, dass von 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> 

Alles in Ordnung scheint, bis ich mein Haupt-Glas entdeckt Artefakt wird nie im Verzeichnis .m2 installiert. Um dies zu korrigieren, habe ich auch die maven-helper-plugin so dass ich manuell alle Artefakte lege ich von der Assembler-Plugin produzieren:

<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> 

Dies führt zu einem Fehler, den ich nicht in der Lage bin zu lösen:

[ERROR] Fehler beim Ausführen des Ziels org.codehaus.mojo: build-helper-maven-plugin: 1.9.1: attach-artefakt (attach-instrumentiert-jar) im Projekt my-project: Ausführung attach-instrumentiert-jar des Ziels org.codehaus. mojo: build-helper-maven-plugin: 1.9.1: attach-artifact fehlgeschlagen: Für artefact {full-name-of-my-project.jar}: Ein angehängtes Artefakt muss eine andere ID als das entsprechende Hauptartefakt haben. -> [Hilfe 1]

Gibt es eine Möglichkeit, dieses Problem zu überwinden? Ich habe nach Lösungen gesucht und empfehle am besten, Klassifikatoren zu verwenden, aber ich möchte das Hauptartefakt wie das maven-jar-plugin installieren. Andere Software, die wir entwickeln, wird die Standard-Jar-Abhängigkeit benötigen, und wir wollen vermeiden, dass unser Setup durch die unangemessene Einführung von Klassifikatoren verkompliziert wird.

Antwort

3

Nach einigen weiteren Versuchen und Fehlern kam ich zufällig mit einer funktionierenden Lösung. Ich poste es hier mit der Hoffnung, entweder nützlich zu sein oder irgendwelche Probleme mit mir zu haben, da ich nicht wirklich zuversichtlich bin, ob dies ein zuverlässiger Ansatz ist.

also der Fehler erhielt ich

Ein angeschlossener Artefakt eine andere ID als ihr entsprechenden Haupt Artefakt haben muss.

bedeutete für mich, dass ich "wieder" das Hauptartefakt manuell nicht installieren kann. Da dieses Artefakt nicht mehr von maven-jar-plugin erzeugt wird, wird es nie für die Installation geplant, selbst wenn die Datei vorhanden ist (die antrun-Kopieraufgabe erzeugt ein jar mit dem gleichen Namen).

Überraschenderweise benötigt es ein paar kleine Tricks wieder diese Arbeit zu machen:

  1. wieder aktiviert die maven-jar-plugin wie es sein sollte:

    <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> 
    

    Dies wird die Standard-Glas auf die Herstellung von package Phase, und am wichtigsten, macht Maven bewusst für sie in der Phase install installiert werden.

  2. Tweak die maven-antrun-plugin Kopieraufgaben zu überschreiben das bereits produzierte Glas mit dem deterministischen Reißverschluss. Der Aufbau ist nahezu identisch wie in meiner Frage, so addiere ich nur die Unterschiede:

    <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> 
    

    Der Kopiervorgang jetzt hat overwrite="true" angegeben. Ursprünglich schien die Kopieroperation Dateien im Ziel zu ignorieren, wenn sie bereits existieren, und was passierte, ist, dass die maven-jar-plugin bereits das Standard-Jar-Artefakt erzeugt hatte, als das Kopieren auftrat. Wenn diese Option gesetzt ist, überschreibt der maven-antrun-plugin nun das vorherige jar mit dem deterministischen, und das letztere wird ein Subjekt der maven install Phase.

  3. das Setup aus der Build-Helfer-Maven-Plugin entfernt, so dass das Haupt jar Artefakt nicht ein zweites Mal kopiert wird:

 

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

Das ist es, das richtige Glas ist in der .m2 Dir installiert.