Apache Maven – Launch4j Integration

Im 4ten Teil der Serie über Maven (Teil 1, Teil 2, Teil 3, Teil 4 – Teil 4 wird für diesen Teil allerdings nicht benötigt, kann also überlesen werden) soll gezeigt werden, wie wiederum Maven genutzt werden kann, um automatisiert im Build-Prozess direkt ausführbare Dateien für Windows (exe) erzeugt werden können.

Launch4j

Launch4j ist ein plattform-übergreifendes Werkzeug zur Erstellung von ausführbaren EXE-Dateien für Windows. Für einmale Aktionen und zum Üben bietet Launch4j eine GUI an, diese eignet sich aber nicht zur Integration in einen Build-Prozess. Hier kann uns Maven wieder helfen.

Erweiterung der pom.xml

Zunächst muss ein (zusätzliches) pluginRepository eingebunden werden. Das Tag pluginRepositories wird nur benötigt, wenn es noch nicht vorhanden war.

<pluginRepositories>
    <pluginRepository>
        <id>launch4j-xml-plugin-repo</id>
        <name>launch4j-xml-plugin Repository for Maven</name>
        <url>

https://launch4j-xml-plugin.googlecode.com/svn/repo

        </url>
    </pluginRepository>
</pluginRepositories>

Anschließend wird wie in Teil 3 der Build-Prozess angepasst. Dazu wird unter /project/build/plugins (dem XPath folgen) folgendes zusätzliche Plugin eingetragen. Es wird davon ausgegangen, dass

  • ein ausführbares JAR-File vorliegt
  • und dieses muss unter plugin/executions/execution/configuration/jar (XPath) angegeben werden

Die gewünschte Ergebnisdatei wird unter plugin/executions/execution/configuration/outfile (XPath) angegeben.

<plugin>
    <groupId>org.bluestemsoftware.open.maven.plugin</groupId>
    <artifactId>launch4j-plugin</artifactId>
    <version>1.5.0.0</version>
    <executions>
        <execution>
            <id>l4j-gui</id>
            <phase>package</phase>
            <goals>
                <goal>launch4j</goal>
            </goals>
            <configuration>
                <headerType>gui</headerType>
                <outfile>target/MouseMover.exe</outfile>
                <jar>target/MouseMover-0.0.1.jar</jar>
                <errTitle>MouseMover Error</errTitle>
                <icon>src/main/resources/mm.ico</icon>
                <jre>
                    <minVersion>1.5.0</minVersion>
                    <maxVersion>1.6.0</maxVersion>
                    <initialHeapSize>128</initialHeapSize>
                    <maxHeapSize>1024</maxHeapSize>
                </jre>
                <versionInfo>
                    <fileVersion>1.0</fileVersion>
                    <txtFileVersion>1.0</txtFileVersion>
                    <fileDescription>Desc</fileDescription>
                    <copyright>C</copyright>
                    <productVersion>1.0</productVersion>
                    <txtProductVersion>1.0</txtProductVersion>
                    <productName>MouseMover</productName>
                    <internalName>MouseMover</internalName>
                    <originalFilename>
                        MouseMover.exe
                    </originalFilename>
                </versionInfo>
            </configuration>
        </execution>
    </executions>
</plugin>

Nach dem nächsten Build steht euch dann an der angegebenen Stelle eine EXE (hier MouseMover.exe) zur Verfügung. Das klappt zum Glück nicht nur unter Windows, sondern auch unter Linux und Mac OS X. Aber das war auch auf der Homepage von Launch4j so angegeben.

Résumé

Launch4j ermöglicht in Verbindung mit Maven das Erstellen von EXE-Dateien ohne große Probleme. So kommen Windows-Nutzer in den Genuss direkt ausführbarer Java-Programme.

Downloads

Das Testprojekt findet sich hier und die enstandene EXE hier.

SPEC Dateien für Red Hat Pakete bekommen

Will man eigene RPM-Dateien erstellen oder vorhandene updaten, so braucht man ein SPEC-File. Diese kann man natürlich selbst erstellen oder bei anderen abschauen. Speziell bei Updates ist das sinnvoll. SPEC-Files sind in den sogenannten SRPM-Dateien der Pakete enthalten. Frei nach einem englischen Artikel kann man diese SRPm-Dateien herunter laden.

Die notwendigen Schritte sind:

yum install yum-utils

Installieren der yum-utils um das Kommando yumdownloader zu erhalten.

Anschließend muss ein Repository für die SRPM-Dateien eingerichtet werden. Dazu editiert man die Datei /etc/yum.repos.d/srpm.repo und fügt folgende Zeilen ein:

[rhel-src]
name=Red Hat Enterprise Linux $releasever - $basearch - Source
baseurl=ftp://ftp.redhat.com/pub/redhat/linux/enterprise/$releasever/en/os/SRPMS/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release

Anschließend kann mit yumdownloader die entsprechende SRPM-Datei heruntergeladen werden:

yumdownloader --source $NAME_DES_PAKETS

Mit dem midnight commander kann das heruntergeladene SRPM dann geöffnet werden, die SPEC-Datei befindet sich dann in der Datei CONTENTS.cpio.

Fernwartungskarten Teil 2

Mal wieder traten die Fernwartungskarten (namentlich unsere Drac5) negativ in Erscheinung. Das Problem diesmal wurde zwar höchstwahrscheinlich durch ein Update auf Windows-Seite ausgelöst, bestand aber nur für die Drac5 Karten. Diese können in den uns vorliegenden (zugegebenermassen etwas älteren) Version 1.33 nur über ein Active-X Plugin auf KVM-Ebene angesprochen werden.

Unter Windows 7 ist im Startmenu der Internet Explorer 2 mal zu finden:

  • Internet Explorer 64bit
  • Internet Explorer

Man könnte ja nun annehmen, der Internet Explorer ohne Bit-Angabe wäre 32bit, oder? War er eventuell auch, nach dem erwähnten Update ist er es jedoch sicher nicht mehr. Man erhält unter beiden Punkten einen 64-bit IE. Will man dort auf die KVM-Konsole der Drac5 per Active-X zugreifen, so scheitert dies ohne klare Fehlermeldung. Es geht halt einfach nicht.

Die Lösung, auf die weder unsere Firmen-Windows-Admins noch der Dell-Premium-Support kamen, ist der Internet Explorer (mit 32 bit!)   direkt aus dem Programmverzeichnis der X86-Anwendungen zu starten. Dort können die benötigten Active-X Plugins dann wieder problemlos ausgeführt werden.

Für die Lösung des Problems danke ich Stefan C.!

GUI-Programme remote auf lokalem Display starten

Vor kurzem hatte ich das Problem, auf einem entfernten Rechner ein GUI-Programm auf dem lokalen X-Display zu starten. Konkret ging es um Teamviewer, ein Programm zum Fernsteuern. Teamviewer ermöglicht den Zugriff auf den Desktop des eingeloggten Nutzers.

Zuerst muss man die Nummer des richtigen Displays herausfinden:

ps ax | grep /usr/bin/X | grep -v grep

Das interessante ist nun

 847 tty7     Ss+   33:48 /usr/bin/X :0 -nr ...

Das Display ist hier “:0″. Setzt man die Variable DISPLAY, so kann man auf diesem X-Server neue Software (in unserem Fall teamviewer) starten:

DISPLAY=":0" teamviewer &

Und schon läuft teamviewer so, dass man remote auf den Desktop zugreifen kann.

Markus “Notch” Persson & Minicraft

Markus “Notch” Persson schlägt wieder zu. Im Rahmen des ludumdare Programmierwettbewerbs hat er in 48 Stunden ein neues Spiel geschrieben:

Minicraft

Das Spielprinzip ist deutlich an Minecraft angelehnt, ist ja auch ein Erfolgsrezept. Ziel des Spiels ist es, das einzige andere empfindungsfähige Wesen zu töten, und somit für immer alleine zusein. Naja ok, Minecraft-typisch muss man das aber nicht…

Nach dem Download des Jar-Files kann man das Spiel mit

java -cp ld22.jar com.mojang.ld22.Game

starten. Alternativ kann das Spiel im Browser gespielt werden. Gesteuert wird die niedliche 8-bit Grafik über die Pfeiltasten und ‘X’ und ‘C’. Im Gegensatz zu Minecraft werden die “Rezepte” zum Bauen von neuen Gegenständen direkt angezeigt und ausgeführt. Sehr praktisch.

Viel Spass beim Erkunden der Gegend.