Wie konfiguriere ich die useCache-Funktion meines Maven-war-Plugins, so dass aufeinanderfolgende Builds schneller sind?

Question

Ich benutze Maven 3.3.0 auf Mac Yosemite. Ich wollte die Funktion useCache des maven-war-plugin verwenden, aber es tut nichts in meinem Multi-Modul-Projekt. Als ich

mvn clean install -DskipTests 

mein Projekt laufen dauert etwa 1:25 mit der unter Konfiguration

<profile> 
    <id>prepare-deploy-war-to-jboss</id> 
    <activation> 
     <file> 
      <exists>${basedir}/src/main/webapp</exists> 
     </file> 
    </activation> 
    <build> 
     <plugins> 
      <plugin> 
       <groupId>org.apache.maven.plugins</groupId> 
       <artifactId>maven-war-plugin</artifactId> 
       <version>2.6</version> 
       <configuration> 
        <useCache>true</useCache> 
        <cacheFile>/tmp/${project.artifactId}/war/work</cacheFile> 
       </configuration> 
      </plugin> 
     </plugins> 
    </build> 
</profile> 

Dann habe ich den gleichen Befehl wieder laufen zu laufen und das Projekt nimmt die gleiche Menge an Zeit. Ich kann sehen, dass "Arbeitsdateien" erstellt werden, so dass das Plugin definitiv läuft, aber aufeinanderfolgende Builds scheinen nichts zu tun zu haben.

Meine Frage hier ist nicht so sehr wie warum ist nicht useCache Beschleunigung meiner Build, aber wie kann ich mein Plugin anders konfigurieren, so dass aufeinander folgende Läufe beschleunigen den Build? Wenn es ein anderes Plugin gibt, das ich verwenden würde, würde dies Builds auf Back-to-Back-Läufen beschleunigen, dann würde das auch hier ausreichen.

Answer 1

am WAR mojo code Blick (zum Zeitpunkt des Schreibens), wird der Cache vor allem durch seine web app structure über overlays management, so in den meisten Fällen verwendet wird, würde es nicht Build-Zeit in der Tat verbessern.

Außerdem ist, wie durch its official documentation erwähnt, ist der Cache-Mechanismus eine experimentellen Funktion, daher standardmäßig deaktiviert, die wahrscheinlich (noch) nicht die Erwartungen der Benutzer nicht erreicht.

---

Unabhängig von der Wirksamkeit dieser Cache-Option, einige Hinweise Maven beschleunigen Builds sein könnte:

• Überlegen Sie, ob Sie brauchen, um clean bei jedem Lauf wirklich
• Betrachten offline Gebäude (-o Option) Wenn alles, was Sie brauchen, ist bereits in Ihrem lokalen Cache
• Verwenden Sie Threads während der Erstellung (-T Option)
• Betrachten Sie ruhig Modus (-q Option), Build-Protokoll vorübergehend ausschalten und nur Fehler-Logs bekommen (im Grunde: keine Nachrichten, gute Nachrichten)
• In Ihrem Fall wird das War Plugin auf die Existenz einer Struktur typischen aktiviert von einer war Verpackung, was wahrscheinlich bedeutet, dass dieses Profil Teil des Aggregator/Eltern Pom und dann nur auf dem Kriegsmodul aktiviert ist. Obwohl es sehr wenig auswirken könnten, sollten Sie auch die War Plugin-Konfiguration auf die betreffende Modul bewegt und Vermeidung einer solchen getriggerten Konfiguration

---

Last but not least, während der Entwicklungszeit, der Zeit bauen ist wahrscheinlich wichtiger als Krieg Größe, so dass Sie den Standard Mechanismus der Wieder Komprimieren externen Bibliotheken ausschalten könnte, um den Krieg-Datei hinzugefügt, über die recompressZippedFiles Option:

Gibt an, ob ZIP-Archiven (jAR, zip, etc.), um den Krieg hinzugefügt werden sollte erneut komprimiert werden. Das erneute Komprimieren kann zu einer kleineren Archivgröße führen, bietet jedoch eine deutlich längere Ausführungszeit.
Standard:

<properties> 
    <war.recompress.files>false</war.recompress.files> 
</properties> 

<build> 
    <finalName>webapp</finalName> 
    <plugins> 
     <plugin> 
      <groupId>org.apache.maven.plugins</groupId> 
      <artifactId>maven-war-plugin</artifactId> 
      <version>2.6</version> 
      <configuration> 
       <recompressZippedFiles>${war.recompress.files}</recompressZippedFiles> 
      </configuration> 
     </plugin> 
    </plugins> 
</build> 

Hinweis: true

So eine Beispielkonfiguration aussehen würde, da es keine Benutzereigenschaft für diesen Konfigurationseintrag ist, habe ich eine Eigenschaft für sie, zu Bei Bedarf über die Befehlszeile (oder über das Profil) ein-/ausschalten.

könnten Sie testen, dann die verschiedenen Zeiten der Ausführung den Standard build Ausführung (mit der Konfiguration über das Deaktivieren Rekompression) gegen die vorherige Konfiguration (unten, Rekompression Einschalten für die aktuelle Ausführung, auf Anfrage):

mvn clean install -Dwar.recompress.files=true 

Sie können dann in Betracht ziehen, profile it je nach Entwicklungsphase ein-/auszuschalten.