Einträge von DeKa

Wenn man Bamboo z.B. auf einem JBOSS benutzen möchte, muss man die bamboo.war nach kleinen Änderungen neu verpacken, damit diese lauffähig ist. So müssen z.B. die WEB-INF/lib/activation.jar und die WEB-INF/lib/mail-1.3.2.jar entfernt werden, damit es nicht zu Classloader-Problemen kommt. Nachdem der Inhalt des Archives in einem Verzeichnis extrahiert wurde, kann mit folgenden Befehl wieder ein WAR-Archiv erstellt werden:


jar -cf atlassian-bamboo-2.1-mod.war -C atlassian-bamboo-2.1 .


Hier die Eclipse-Update-URLs:

Maven4Eclipse: http://m2eclipse.codehaus.org/update/ bzw. http://m2eclipse.sonatype.org/update-dev/

Subclipse: http://subclipse.tigris.org/update_1.2.x

Eclipse Checkstyle: http://eclipse-cs.sourceforge.net/update

Wenn man mit Maven eine JAR-Datei baut, werden die abhängigen Bibliotheken, im Gegensatz zu WAR-Archiven, normalerweise nicht mit in das erstellte Artefakt inkludiert. Dies ist meistens auch sinnvoll, da die notwendigen Resourcen nicht mehrfach abgelegt werden sollen und bei Bedarf leicher austauschbar sind. Möchte man jedoch eine lauffähige Anwendung verbreiten, ist es zwingend notwendig, dass alle Abhängigkeiten vorhanden sind.

Als Lösung dafür sieht Maven das maven-assembly-plugin vor, welches alle Dateien (wie z.B. die Klassen-Dateien, Skripte, Property-Dateien, Bibliotheken, etc), die für einen Release notwendig sind, in einem Archiv (z.B. jar, zip, tar, gzip tar, als Verzeichnis, etc.) zusammenstellt.

Das Assembly-Plugin kann auch verwendet werden, um eine ausführbare JAR-Datei zu erstellen.

So wäre es schön, eine ausführbare JAR-Datei zu erstellen, die den eigenen Programmcode und alle Abhängigkeiten enthält.
Leider kann Java die benötigten Bibliotheken nicht aus der selben JAR-Datei laden, die auch die Main-Klasse enthält, sodass man entweder

1. einen eigenen (angepassten) Class-Loader verwenden muss,


2. oder alle Klassen auspacken und anschließend in eine einizige JAR-Datei verpackt (Scheidet aus, wenn man vorhandene signierte JAR-Dateien verwenden muss.)


3. oder die JAR-Dateien in eine weitere JAR-Datei verpacken muss.

"Maven: JAR mit Abhängigkeiten bauen" vollständig lesen

Um ein JAR-Archiv lauffähig zu machen, muss die Konfiguration des maven-jar-plugins in der pom.xml angepasst werden, aufdass die Hauptklasse im MANIFEST.MF aufgeführt wird:


<project>
...
  <build>
    <plugins>
      <plugin>
        <artifactId>maven-jar-plugin</artifactId>
        <configuration>
          <archive>
            <manifest>
              <mainClass>com.example.App</mainClass>
            </manifest>
          </archive>
        </configuration>
      </plugin>
    </plugins>
  </build>
  <dependencies>
...
<project>


Nach einem

$ mvn clean package

kann man das Archiv mit

$ java -jar ./target/Artifakt-1.0-SNAPSHOT.jar

nun direkt ausführen (Artifakt-1.0-SNAPSHOT.jar durch den Namen der erzeugten Datei ersetzen).

Schreibt man ein Programm, dass mehrere Frameworks benutzt, kann es vorkommen, dass diese Bibliotheken verschiedener Versionen benutzen, die nicht zueinander kompatibel sind. Eine typische Fehlermeldung, die auf diesen Fakt hinweist, ist z.B. ein java.lang.NoSuchMethodError. Diese begegnet mir z.b. ständig, wenn verschiedene Versionen von commons-collections benutzt werden.

Mit dem Befehl

mvn dependency:tree -Dverbose -Dincludes=commons-collections

listete Maven einen Baum von Abhängigkeiten zu z.B. commons-collections auf.
"Maven: Abhängigkeitskonflikte finden" vollständig lesen

Beim JBoss Application Server ist das Access-Logfile standardmäßig deaktiviert.
Möchte man die Zugriffe der Clients protokollieren, muss man in der Datei
${JBOSS_HOME}/server/${PROFILE}/deploy/jboss-web.deployer/server.xml
folgenden Abschnitt entkommentieren:

<Valve className="org.apache.catalina.valves.FastCommonAccessLogValve"
prefix="localhost_access_log." suffix=".log" pattern="common"
directory="${jboss.server.home.dir}/log" resolveHosts="false" />


Auf unserem Backup-System gibt es viele Cron-Jobs, die täglich viele Dinge tun, um diverse FeM-Kisten zu backup-en.
Damit nicht jeder dieser Cron-Jobs sinnloserweise eine Mail schickt, kann man mit

| logger -t meintagname

die Ausgaben an den Syslog umleiten und dann nach diversen Kriterien sortieren.
Durch die Angabe eines Tags 'meintagname' tauchen die Ausgaben unter diesem Tag im Logfile auf.
Schlägt ein Cron-Job fehl, wird weiterhin eine Mail verschickt.

Möchte man ein Backup eines Subversion-Repositories erstellen, hat man prinzipiell drei Möglichkeiten:

• einen Dump vom Repository erstellen


• das komplette Verzeichnis des Repositories zu sichern


• mit svnsync das Repository kopieren

Mit svnsync ist es möglich, ein Repository von einer Maschine auf eine andere zu kopieren.
Wie man svnsync benutzt, ist z.B. hier beschrieben.

Da ich keine Lust habe, mir das Thema bei jedem Anlegen eines Repositories neu zu erarbeiten,
habe ich ein kleines Skript names 'svn-create-backup' geschrieben.

Nun braucht man bei jedem Anlegen eines neuen Repositories auf der Backup-Maschine nur einen Einzeiler auszuführen:
./svn-create-backup meinrepository
"Subversion: Backups mit svnsync erstellen" vollständig lesen

(Notiz an mich)

Unter Gentoo geht das Installieren eines Java SDKs bekanntlich einfach:
emerge sun-sdk -avt

Was ich jedoch immer wieder vergesse:
Nach einem Update des SDKs kann es unter Umständen passieren, dass man das verwendete SDK noch umschalten muss:
java-config --set-system-vm sun-jdk-1.6

Die aktuelle Konfiguration kann man mit
java-config --show-active-vm
und
java-config --list-available-vms
überprüfen.

Quelle:
http://www.gentoo.org/doc/de/java.xml

Das Versionskontrollsystem Subversion ist eine in C geschriebene Programmbibliothek. Man hat verschiedene Nutzerschnittstellen, wie z.B. ein Kommandozeilentool "svn" zur Verfügung, dass diese Bibliothek über eine definierte Schnittstelle (API) benutzt.

Zusätzlich stellt das Entwicklerteam mehrere Sprachbindungen für andere Programmiersprachen zur Verfügung, damit diese Bibliothek auch von Drittsoftware (in anderen Programmiersprachen) benutzt werden kann. Die mitgelieferte Sprachbindung für Java nennt sich z.B. JavaHL.

Ein Vorteil von Java ist es, dass man entwickelte Software plattformübergreifend nutzen kann. Verwendet man JavaHL ist dies nicht mehr gegeben, da man die native Subversion-Bibliothek auf den Zielsystem installiert haben muss, um Subversion in Java zu nutzen.

Um dieses Problem zu lösen, existiert ein Projekt namens "SvnKit" (ehemals "JavaSVN"), dass sich zur Aufgabe gemacht hat, eine 100%ige Java-Implementierung des Subversion-Protokolls zu realisieren.

Einige Dritthersteller, wie z.B. Atlassian (Jira) oder CollabNet (Subclipse), sind dazu übergegangen, von JavaHL auf SvnKit umzustellen.

Zur Zeit lese ich das Buch "Konfigurations-Management mit Subversion, Ant und Maven" von Gunther Popp (ISBN 3-89864-416-2, 53 INF ST 230 P831). Obwohl ich nicht erwartet habe noch etwas neues über Subversion zu lernen, habe ich auf Seite 123 einen Aspekt gefunden, die ich noch nicht kannte:

Die sog. "PEG-Revision". Die Peg-Revision legt den Aufsetzpunkt des History-Tracings fest. In der Praxis benötigt man Peg-Revisionen meistens dann, wenn im Projekt Refactoring- oder Umstrukturierungen rückgängig gemacht werden sollen. Möchte man eine gelöschte Datei aus einer älteren Revision für zukünfitge Revisionen wiederherstellen, sollte man die Datei nicht einfach im Dateisystem kopieren. Denn in diesem Fall legt das Subversion die komplette Datei neu im Repository ab und behandelt diese, als wäre es eine vollkommen neue Datei. Stattdessen sollte man die Datei mit dem "svn copy" Befehlt wiederherstellen und behält dadurch die Historie der Datei bei:

svn copy MeineDatei.txt@5 MeineDatei.txt
(Wobei die 5 durch die Revision zu ersetzen ist, in der die Datei im Repository noch vorhanden war)

Im Buch ist dazu eine Zeile gelistet, mit der man die Historie einer Datei rückverfolgen kann, auch wenn sie in der aktuellen Revision nicht mehr vorhanden ist:

svn list -r2 src/java/e2etrace/timer/DefaultTimer.java@5

Der Total Commander wird in der Schweiz entwickelt. Wegen den dortigen Patent- und Kryptographie-Exportgesetzen darf der Total Commander keine integierte Verschlüsselung unterstützen. Mit einem Dateisystem-Plugin von einem deutschen Server kann man diese Funktionalität jedoch nachrüsten:

1. von http://developer.berlios.de/projects/sftp4tc/ das SFTP-Plugin (kann auch SCP) herunterladen


2. das Plugin-Archiv in beliebiges Verzeichnis entpacken


3. im Total Commander, "Konfigurieren" - "Optionen" - "Operation" - "DS-Plugins" auswählen


4. auf "Hinzufügen" klicken


5. die .wfx-Datei des Plugins auswählen und auf OK klicken
   

...auf diese Weise kann man z.B. auch ext2 oder WebDAV nachrüsten.

Wenn man mal in die Verlegenheit kommt, eine Änderung in einem Subversion-Repository mit dem falschen Nutzernamen gemacht zu haben, dann kann man den Autor nochmal nachträglich ändern mit:

svn propset svn:author 'spi-team' -r690 --revprop

(spi-team durch den neuen Autor ersetzen, 690 durch betreffende Revision ersetzen)

Damit die Änderung auch funktioniert, muss ein sog. 'pre-revprop-change' Hook auf dem Server in $REPOSITORY/hook/pre-revprop-change ($REPOSITORY durch das Repository-Verzeichnis ersetzen) existieren und vom Server (in meinem Fall vom Apache) ausführbar sein:

#!/bin/sh
REPOS="$1"
REV="$2"
USER="$3"
PROPNAME="$4"
ACTION="$5"
if [ "$ACTION" = "M" -a "$PROPNAME" = "svn:log" ]; then exit 0; fi
if [ "$ACTION" = "M" -a "$PROPNAME" = "svn:author" ]; then exit 0; fi
echo "Changing revision properties other than svn:log and svn:author is prohibited" >&2
exit 1

Um den Jboss unter Windows als Systemdienst einzurichten, existiert ein kleiner Wrapper namens JBossService.exe:

JBossService -install JBossService %JAVA_HOME%/jre/bin/server/jvm.dll -Djava.class.path=%JAVA_HOME%/lib/tools.jar;%JBOSS_HOME%/bin/run.jar -Xmx400M -start org.jboss.Main -params -c default -stop org.jboss.Main -method systemExit -out %JBOSS_HOME%/server/default/log/stdout.log -err %JBOSS_HOME%/server/default/log/stderr.log -current %JBOSS_HOME%/bin

Ich höre von einigen Bekannten/Freunden immer wieder, dass Maven sicher toll, es aber keinerlei Dokumentation dazu gibt. So ganz simmt das nicht: Das Maven-User-Guide gibt einen netten Einblick darauf, wie Maven funktioniert und man damit effektiv arbeitet.