Custom Maven Assembly

Question

Ich beginne mit Maven zu arbeiten, denke aber noch nicht erfolgreich in Mavens Begriffen nach. Ich habe eine spezifische Anforderung und die Dokumentation gibt mir nicht genug Anhaltspunkte, so konnte ich ein bisschen Hilfe gebrauchen:

Ich mag eine Anordnung schaffen, dass

1. baut ein jar-with-dependencies wie die "Standard" Ziel dieses Namens, aber ein paar der Ressourcen ausgeschlossen. Ich möchte log4j.properties und ein paar andere Konfigurationsdateien zu nicht im Glas sein.

2. baut eine .ZIP Datei in ihrem Stammverzeichnis Dateien die .jar aus Schritt 1 sowie die oben genannten Konfiguration enthält.

Ich mag diese Versammlung feuern von der Kommandozeile (nur), also keine Notwendigkeit, eine Phase zu binden (oder Ziel? Mojo?). Vorzugsweise verwendet man entweder assembly:assembly oder .

• Muss ich einen benutzerdefinierten Assembly Descriptor dafür brauchen?
• Und ist es wahr, ich kann es nicht in der pom.xml verschachteln? So geht es in src/assembly/something.xml und wird mit einem descriptorRef referenziert?
• Kann ich dies als zwei relativ einfache Assemblys definieren, von denen eines auf dem anderen aufbaut (d. H. Die .Zip-Assembly verwendet die .Jar-Assembly) oder muss ich alles in einer Assembly tun?

Answer 1

Ich fange mit Maven zu arbeiten, aber bin noch nicht erfolgreich in Maven Begriffen zu denken.

Willkommen an Bord, Carl! : D

Ich möchte diese Versammlung von der Kommandozeile (nur) abfeuern, also keine Notwendigkeit, an eine Phase (oder Ziel? Mojo?) Zu binden. Bevorzugt verwenden beide Montage: Montage oder Montage: Single.

Nur um zu klären: die build lifecycle selbst ist aus phases (kompilieren, testen, Paket, usw.) und Plug-Ziele (technisch Mojos) auf Phasen gebunden. Sie rufen dann entweder eine Phase ... oder nur ein bestimmtes Plugin-Ziel auf.

Benötige ich einen benutzerdefinierten Assembly-Deskriptor?

Nun, da Sie Verhalten wollen, dass die pre-defined descriptors nicht abdecken, ja. Sie werden sogar zwei davon benötigen (für den Überar, einen für den Reißverschluss).

Und ist es wahr, ich kann es nicht in der pom.xml verschachteln? Also geht es in src/assembly/something.xml und wird mit einem descriptorRef referenziert?

Ja, das ist wahr (Deskriptoren verwenden, um ein benutzerdefiniertes Format), und sie gehen in der Regel in src/main/assembly.Und nein, descriptorRef ist für den Einbau-Deskriptoren, müssen Sie descriptor hier verwenden.

Kann ich dies als zwei relativ einfache Baugruppen codieren, von denen eine auf der anderen Seite baut (das heißt die .zip-Baugruppe verwendet die .jar-Montage) oder habe ich alles in einer Baugruppe zu tun?

Wie angedeutet, benötigen Sie zwei Assembly Deskriptoren. Lassen Sie mich ein wenig helfen ...

Nehmen wir an, Sie folgende Projektstruktur:

 
$ tree . 
. 
├── pom.xml 
└── src 
    ├── main 
    │   ├── assembly 
    │   │   ├── jar.xml 
    │   │   └── zip.xml 
    │   ├── java 
    │   │   └── com 
    │   │    └── stackoverflow 
    │   │     └── App.java 
    │   └── resources 
    │    └── log4j.properties 
    └── test 
     └── java 
      └── com 
       └── stackoverflow 
        └── AppTest.java 

Wo die pom.xml die folgende Konfiguration für die Montage Plugin enthält:

<project> 
    ... 
    <dependencies> 
    ... 
    </dependencies> 
    ... 
    <build> 
    <plugins> 
     <plugin> 
     <artifactId>maven-assembly-plugin</artifactId> 
     <version>2.2-beta-5</version> 
     <configuration> 
      <descriptors> 
      <descriptor>src/main/assembly/jar.xml</descriptor> 
      <descriptor>src/main/assembly/zip.xml</descriptor> 
      </descriptors> 
     </configuration> 
     </plugin> 
    </plugins> 
    </build> 
</project> 

Der Deskriptor für Das "gefilterte" Uberjar (jar.xml) sieht wie folgt aus:

<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0 http://maven.apache.org/xsd/assembly-1.1.0.xsd"> 
    <id>uberjar</id> 
    <formats> 
    <format>jar</format> 
    </formats> 
    <includeBaseDirectory>false</includeBaseDirectory> 
    <dependencySets> 
    <dependencySet> 
     <unpack>true</unpack> 
     <scope>runtime</scope> 
     <useProjectArtifact>false</useProjectArtifact> 
    </dependencySet> 
    </dependencySets> 
    <fileSets> 
    <fileSet> 
     <directory>${project.build.outputDirectory}</directory> 
     <outputDirectory>/</outputDirectory> 
     <excludes> 
     <exclude>log4j.properties</exclude> 
     </excludes> 
    </fileSet> 
    </fileSets> 
</assembly> 

Was dieser Deskriptor tut, ist (kurz):

• die Abhängigkeiten enthalten, entpacken Sie sie, aber ausschließen, das Projekt selbst (ja, das ist unlogisch, aber diese seltsame Standardverhalten ist für die Abwärtskompatibilität gehalten wurde)
• umfassen die Projektdateien, aber einige von ihnen auszuschließen.

Und der Deskriptor für die zip (zip.xml) sieht wie folgt aus:

<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0 http://maven.apache.org/xsd/assembly-1.1.0.xsd"> 
    <id>bin</id> 
    <formats> 
    <format>zip</format> 
    </formats> 
    <includeBaseDirectory>false</includeBaseDirectory> 
    <fileSets> 
    <fileSet> 
     <directory>${project.basedir}/src/main/resources</directory> 
     <outputDirectory/> 
     <includes> 
     <include>log4j.properties</include> 
     </includes> 
    </fileSet> 
    <fileSet> 
     <directory>${project.build.directory}</directory> 
     <outputDirectory/> 
     <includes> 
     <include>*-uberjar.jar</include> 
     </includes> 
    </fileSet> 
    </fileSets> 
</assembly> 

das ist (irgendwie) selbsterklärend :)

• es die Konfigurationsdateien enthält (relativ zu <directory>) an der Wurzel der Baugruppe
• es enthält das Uberjar (relativ zu <directory>) an der Wurzel der Baugruppe
Schließlich

, laufen nur mvn assembly:assembly (dass das Ziel ist beabsichtigt, auf der CLI verwendet werden).

---

ich nicht (wissentlich) umfassen META-INF/Maven/** in der Versammlung für die uberjar. Gibt es eine einfache Möglichkeit, die Aufnahme dieser zu verhindern?

Diese stammen aus den Bibliotheken, die entpackt sind. Sie können sie mit unpackOptions ausschließen. Hier ist eine modifizierte Version des jar.xml:

<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0 http://maven.apache.org/xsd/assembly-1.1.0.xsd"> 
    <id>uberjar</id> 
    <formats> 
    <format>jar</format> 
    </formats> 
    <includeBaseDirectory>false</includeBaseDirectory> 
    <dependencySets> 
    <dependencySet> 
     <unpack>true</unpack> 
     <scope>runtime</scope> 
     <unpackOptions> 
     <excludes> 
      <exclude>META-INF/maven/**</exclude> 
     </excludes> 
     </unpackOptions> 
     <useProjectArtifact>false</useProjectArtifact> 
    </dependencySet> 
    </dependencySets> 
    <fileSets> 
    <fileSet> 
     <directory>${project.build.outputDirectory}</directory> 
     <outputDirectory>/</outputDirectory> 
     <excludes> 
     <exclude>log4j.properties</exclude> 
     </excludes> 
    </fileSet> 
    </fileSets> 
</assembly>