Benutzerdefinierte Maven-Assembly

8

Ich fange an, mit Maven zu arbeiten, denke aber noch nicht erfolgreich in Mavens Worten nach. Ich habe eine bestimmte Anforderung und die Dokumente geben mir nicht genügend Hinweise, also könnte ich ein bisschen Hilfe gebrauchen:

Ich möchte eine Baugruppe erstellen, die

  1. erstellt ein jar-with-dependencies wie das "Standard" -Ziel dieses Namens, schließt jedoch einige Ressourcen aus. Ich möchte log4j.properties und ein paar andere Konfigurationsdateien zu nicht im Jar finden.

  2. erstellt eine .ZIP -Datei, die in ihrem Wurzelverzeichnis die .jar von Schritt 1 sowie die oben erwähnten Konfigurationsdateien enthält.

Ich möchte diese Assembly nur von der Kommandozeile aus feuern, daher muss man nicht mit einer Phase (oder einem Ziel? mojo?) verbunden werden. Vorzugsweise verwenden Sie entweder assembly:assembly oder assembly:single .

  • Benötige ich einen benutzerdefinierten Assembly-Deskriptor?
  • Und ist es wahr, dass ich es nicht in pom.xml verschachteln kann? Also geht es in src/assembly/something.xml und wird mit einem descriptorRef ?
  • referenziert
  • Kann ich das 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 machen?
Carl Smotricz 16.08.2010, 13:07
quelle

1 Antwort

27
  

Ich fange an, mit Maven zu arbeiten, denke aber noch nicht erfolgreich in Mavens Worten nach.

Willkommen an Bord, Carl! : D

  

Ich möchte diese Assembly nur von der Kommandozeile aus feuern, daher muss man nicht mit einer Phase (oder einem Ziel? mojo?) verbunden werden. Verwenden Sie vorzugsweise beide Baugruppen: Montage oder Montage: einzeln.

Nur um klarzustellen: Der Build-Lebenszyklus selbst besteht aus phases (kompilieren, testen, Paket usw.) und Plugin-Ziele ( technisch Mojos) sind an 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 vordefinierten Deskriptoren nicht verwenden bedecke nicht, ja. Sie werden sogar zwei davon brauchen (für den Überar, einen für den Reißverschluss).

  

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

Ja, das stimmt (Deskriptoren verwenden ein benutzerdefiniertes Format) und sie gehen normalerweise in src/main/assembly . Und nein, descriptorRef ist für die eingebauten Deskriptoren, Sie müssen descriptor hier verwenden.

  

Kann ich das 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?

Wie bereits angedeutet, benötigen Sie zwei Assembly-Deskriptoren. Lass mich ein bisschen helfen ...

Nehmen wir an, Sie haben die folgende Projektstruktur:

%Vor%

Wo pom.xml die folgende Konfiguration für das Assembly-Plugin enthält:

%Vor%

Der Deskriptor für das "gefilterte" Uberjar (jar.xml) sieht folgendermaßen aus:

%Vor%

Was dieser Deskriptor macht, ist (kurz):

  • schließt die Abhängigkeiten ein, entpacke sie, aber schließe das Projekt selbst aus (ja, das ist kontraintuitiv, aber dieses seltsame Standardverhalten wurde aus Gründen der Abwärtskompatibilität beibehalten)
  • enthält die Projektdateien, schließt aber einige aus.

Und der Deskriptor für die Zip (zip.xml) sieht so aus:

%Vor%

Was (irgendwie) selbsterklärend ist:)

  • Es enthält die Konfigurationsdateien (relativ zu <directory> ) im Stammverzeichnis der Assembly
  • Es enthält den Uberjar (relativ zu <directory> ) im Stammverzeichnis der Assembly

Führen Sie schließlich mvn assembly:assembly aus (das ist das Ziel, das auf der CLI verwendet werden soll).

  

Ich habe (wissentlich) META-INF / maven / ** in die Versammlung für den Uberjar nicht eingeschlossen. Gibt es einen einfachen Weg, um die Einbeziehung dieser zu verhindern?

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

%Vor%     
Pascal Thivent 16.08.2010, 16:29
quelle