Maven appassembler Plugin: Der Umgang mit langen Klassenpfaden unter Windows

Wenn es um die Erstellung von Befehlszeilenskripten für Java-Anwendungen geht, ist das Maven Plugin "appassembler" sehr nützlich. Sein "assemble"-Ziel übernimmt die gesamte Maven-Magie, d.h. die Suche nach den Abhängigkeiten, die für die Erstellung der Java-Anwendung verwendet werden, das Hinzufügen dieser Abhängigkeiten zum Klassenpfad des resultierenden Skripts und schließlich das Kopieren aller relevanten Jars an einen einzigen Ort. Das funktionierte alles sehr gut, bis ich über das Problem der langen Klassenpfade im Windows-Betriebssystem stolperte. Unabhängig davon, ob Sie die DOS-Eingabeaufforderung oder Cygwin verwenden, begrenzt Windows die Länge der Umgebungsvariablen. Es gibt zwar verschiedene Möglichkeiten, dieses Problem zu lösen, z.B. durch die Verwendung von Java 6 Wildcard-Klassenpfaden, die Zuordnung des Pfads zu einem Laufwerk usw., aber das sind für mich alles nur Notlösungen, da das Problem jederzeit wieder auftauchen kann.

Nach einiger Recherche habe ich herausgefunden, dass das appassembler plugin dieses Problem mit den Daemons booter-windows und booter-unix löst. Auf den ersten Blick sah es so aus, als ob der Daemon etwas anderes macht, da der Name etwas irreführend ist, aber in Wirklichkeit handelt es sich um eine generische Möglichkeit, Ihre Java-Anwendungen zu starten. Die Plattformen booter-unix/booter-windows wurden ausschließlich zu dem Zweck eingeführt, das Problem des langen Klassenpfads (siehe MAPPASM-43) im Maven-Plugin appassembler zu lösen. Hier sehen Sie, wie es in dem pom aussieht, mit dem Sie arbeiten: [xml listing="2"] <Plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>appassembler-maven-plugin</artifactId> <Konfiguration> <repositoryLayout>flach</repositoryLayout> <installArtifacts>false</installArtifacts> <target>${project.build.directory}/appassembler</target> <defaultJvmSettings> <initialMemorySize>512M</initialMemorySize> <maxMemorySize>1024M</maxMemorySize> <extraArgumente> <extraArgument>-DconfigFile=../../etc/config.properties</extraArgument> <extraArgument>-Dlog4j.configuration=../../etc/log4j.properties</extraArgument> </extraArguments> </defaultJvmSettings> <configurationDirectory>etc</configurationDirectory> <Dämonen> <Dämon> <id>anwendungsname</id> <mainClass>com.xebia.appassebler.sample.Main</mainClass> <Plattformen> <Plattform>booter-unix</Plattform> <Plattform>booter-windows</Plattform> </platforms> <environmentSetupFileName>app-env</environmentSetupFileName> </daemon> </daemons> </configuration> <Hinrichtungen> <Ausführung> < Phase>Paket</Phase> <Ziele> <Ziel>Dämonen erzeugen</Ziel> <goal>create-repository</goal> </goals> </execution> </executions> </plugin> [/xml] Wenn Sie sich den Code genau ansehen, werden Sie "app-env" als Parameter des Tags "environmentSetupFileName" finden. Er ist sehr nützlich, um Umgebungsvariablen an das resultierende Skript zu übergeben. Mit den Umgebungsdateien app-env (für UNIX) und app-env.bat (für Windows) kann ich eine geänderte Umgebungsvariable $REPO übergeben, so dass das kopierte Repository, das die Abhängigkeiten enthält, von den Ordnern booter-unix und booter-windows wie folgt gemeinsam genutzt wird:

|-- booter-unix
| |-- bin
| | |-- applicationName
| | `-- app-env
| `-- etc
| `-- anwendungsname.xml
|-- booter-windows
| |-- bin
| | |-- app-env.bat
| | `-- anwendungsname.bat
| `-- etc
| `-- anwendungsname.xml
|-- usw.
|-- config.properties
| `-- log4j.properties
`-- Repo
  |--  <Abhängigkeit1>.jar
  |--  <Abhängigkeit2>.jar
  |-- ...

Um die Umgebungsdateien und das Ergebnis des Maven-Ziels appassembler:generate-daemons an die entsprechenden Stellen zu kopieren, können wir "maven-assembly-plugin" wie folgt verwenden: [xml] <Plugin> <artifactId>maven-assembly-plugin</artifactId> <Konfiguration> <descriptor>src/main/conf/descriptor.xml</descriptor> </configuration> <Hinrichtungen> <Ausführung> <Ziele> <Ziel>einzeln</Ziel> </goals> <Phase>Paket</Phase> </execution> </executions> </plugin> [/xml] So sieht die Datei src/main/conf/assembly.xml aus: [xml] <Montage> <id>bin</id> <Formate> <format>tar.gz</format> <formatieren>zip</formatieren> <format>dir</format> </formats> <fileSets> <fileSet> <Verzeichnis>target/appassembler/booter-unix</Verzeichnis> <outputDirectory>/booter-unix</outputDirectory> <schließt aus.> <ausschließen>.bat</exclude > <exclude>.cmd</exclude> </excludes> <lineEnding>unix</lineEnding> <fileMode>0744</fileMode> </fileSet> <fileSet> <Verzeichnis>target/appassembler/booter-windows</Verzeichnis> <outputDirectory>/booter-windows</outputDirectory> </fileSet> <fileSet> <Verzeichnis>target/appassembler/repo</Verzeichnis> <outputDirectory>/repo</outputDirectory> </fileSet> <fileSet> <Verzeichnis>src/main/conf</Verzeichnis> <enthält> <include>app-env.bat</include> </includes> <outputDirectory>/booter-windows/bin</outputDirectory> </fileSet> <fileSet> <Verzeichnis>src/main/conf</Verzeichnis> <enthält> <include>app-env</include> </includes> <outputDirectory>/booter-unix/bin</outputDirectory> <lineEnding>unix</lineEnding> </fileSet> </fileSets> </assembly> [/xml] Wenn Sie nun "mvn clean package" ausführen, erhalten Sie die in Listing 2 beschriebene Struktur. Sie können das Skript unter Windows mit booter-windows/bin/applicationName.bat ausführen, ohne sich um lange Klassenpfade zu kümmern.