
- patterntesting.concurrent.experimental.ParallelProxyRunner
- patterntesting.concurrent.junit.ParallelSuite
What's else new? Some testers (ComparableTester and RuntimeTester) were added, an uberjar for patterntesting-rt is now provided and some bugs are fixed. For more changes read the release notes.
Happy PatternTesting
... link (0 Kommentare) ... comment

- mehr Sport treiben (mind. 2 Stunden pro Woche),
- mit der App-Entwicklung für iPhone und iPad anfangen und
- sich von Facebook zu verabschieden.
Frohe Neues Jahr!
... link (0 Kommentare) ... comment

Abends wird dann 10 Jahre PatternTesting gefeiert. Hier besteht dann die Gelegenheit, sich in gemütlicher Runde mit anderen Teilnehmern auszutauschen und auch über Themen abseits von Java und Testen zu diskutieren.
Damit wir den Teilnehmern einen kostenlosen Eintritt ermöglichen können, haben wir mit T-Systems einen Premium-Sponsor gewinnen können. Aber wir brauchen noch weitere Sponsoren - wer hier uns gerne unterstützen wollen, findet unter www.jugs.org/tt2012/sponsoring.html weitere Informationen bzw. kann unter aop@jugs.org weitere Infos anfordern.
Auf ein erfolgreiches und test-getriebenes 2012
... link (0 Kommentare) ... comment

@Test @SkipTestOn(property="SKIP_EXPORT_TEST") public void testEmptyExport() throws IOException { ... }Sobald dieser Test mit der Option -DSKIP_EXPORT_TEST aufgerufen wird, wird der Test ausgeblendet. Wichtig dabei ist, dass der SmokeRunner oder ParallelRunner als Testrunner verwendet wird:
@RunWith(SmokeRunner.class) public final class DatenpaketTest { … }Man kann auch mehrere Optionen angeben:
@Test @SkipTestOn(property={"SKIP_IMPORT_TEST","SKIP_EXPORT_TEST"}) public void testImportExport() throws IOException { ... }Sobald eine der beiden Properties gesetzt ist, wird der Test ausgeblendet.
Das Ganze kann man mit @RunTestOn auch andersrum machen: man definiert sich eine Property, und nur wenn diese Property gesetzt ist, wird der Test auch ausgeführt. Problematik dabei ist, dass man hier immer alle Properties angeben muss, wenn man alle Tests ausführen will. Ist keine Property gesetzt, wird auch kein Test ausgeführt. Ansonsten sind aber beide Verfahren gleichwertig.
... link (0 Kommentare) ... comment

Die iJUG ist ein Dachverband der Java User Groups im deutschsprachigen Raum, der auch die JUGS angehört. Eines der Ziele der iJUG ist es, den User Groups ein stärkeres Gewicht gegenüber Oracle zu geben, was mir seit der Übernahme durch Sun dringend nötig erscheint.
... link (0 Kommentare) ... comment
Vorbereitungen
Im wesentlichen unterscheidet sich ein Bundle von einer normalen Jar-Datei dadurch, dass unter META-INF/MANIFEST.MF zusätzliche Meta-Informationen wie- exportierte Packages
- importierte Packages
- und mehr (z.b. importierte Packages)
Man kann die MANIFEST.MF-Datei manuell erstellen, besser und weniger fehleranfällig ist es aber, wenn man dazu die BND-Tools benutzt. Benötigt wird hiervon die Jar-Datei
biz.aQute.bnd.jar.
Falls man mit Eclipse arbeitet, bieten sich auch die bnd-tools als Eclipse-Pluginan, die über die Update-Site http://bndtools-updates.s3.amazonaws.com installiert werden können. Dieses Plugin bietet u.a. einen Viewer für Jar-Dateien an, mit dem man recht komfortabel den Inhalt der Jars und deren Manifest-Datei anschauen kann.
Analyse DB2Driver
Am Beispiel des JDBC-Treibers für DB2, der als Päärchen db2jcc.jar und db2jcc_license_cu.jar daherkommt, wollen wir uns an den Bau eines OSGi-Bundles machen. Fangen wir mit der ersten Jar-Datei, db2jcc.jar, an. Folgende Informationen (neudeutsch: Properties) benötigen wir für das Bundle:Bundle-Name: db2jcc Bundle-Description: DB2 JDBC driver Bundle-SymbolicName: Bundle-Version: Bundle-RequiredExecutionEnvironment: Export-Package: Import-Package: Private-Package:Diese Information schreiben wir in die Datei db2jcc.bnd, die in dieser Form von den BND-Tools als Steuer-Datei benutzt werden kann. Die ersten beiden Einträge sind schon ausgefüllt und benötigen eigentlich keiner weiteren Erklärung.
Als Bundle-SymbolicName wird für Jar-Dateien, die bereits als OSGi-Bundles vorliegen, meist der oberste Package-Namen verwendet. So verwendet Commons Lang von Apache "org.apache.commons.lang" als symbolischen Namen. Bei Jar-Dateien, die noch nicht als OSGi-Bundle vorliegen, hat es sich eingebürgert, hier noch den Namen des Projekts oder der Firma voranzustellen, um es von den Original-Jar-Dateien abzugrenzen. In unserem Fall verwenden wir also nicht "com.ibm.db2jcc", sondern z.B. "de.blogger.oli.com.ibm.db2jcc". Man kann aber auch einen beliebigen anderen Namen hierfür verwenden.
Bei der Bundle-Version nimmt man am besten die Version des Treibers. Dies ist im Falle von dbj2cc.jar schon etwas schwieriger, da man diese Version auch nicht innerhalb der Jar-Datei findet. Unter DB2 JDBC Driver Versions findet man aber einige Hinweise, um welche Version es sich handeln könnte (hier war es die Version 3.53.70).
Für die Bundle-RequiredExecutionEnvironment müssen wir wissen, welche Java-Version wir mindestens benötigen. Dazu finden wir in der Manifest-Datei den Hinweis, dass sie mit JDK 1.4.2 gebaut wurde, d.h. der Treiber ist unter J2SE-1.4, J2SE-1.5 und JavaSE-1.6 lauffähig.
Über Export-Package gibt man bekannt, welche Packages nach außen sichtbar sein sollen. Ein Blick in die Jar-Datei lässt vermuten, dass dies die Packages "com.ibm.db2.jcc" und "sqlj.runtime", sowie alle Packages unter "COM.ibm.*" und "sqlj.runtime.*" sind.
Bei Import-Package kann man es sich einfach machen und einfach "*" als Wildcard eingeben. Dann ermittelt das BND-Tool die Imports selbst - allerdings kann er nur die direkten Imports erkennen oder schießt manchmal auch über das
Ziel hinaus und findet auch Imports, die nur in Ausnahmefällen benötigt werden. Da es sich in unserem Fall um einen JDBC-Treiber handelt und dafür die Packages "java(x).sql" benötigt werden, helfen wir BND mit com.ibm.db2.jcc.licenses, java.sql*, javax.sql*, *;resolution:=optional auf die Sprünge. *;resolution:=optional bedeutet dabei, dass alle restlichen Imports optional sein sollen.
Bei Private-Package machen wir es uns einfach - alles was übrig bleibt, kennzeichen wir als "private". Damit ergeben sich folgende Einträge für db2jcc.bnd:
bsn: de.blogger.oli.com.ibm.db2jcc version=3.53.70 Bundle-Name: db2jcc Bundle-Description: DB2 JDBC driver Bundle-SymbolicName: ${bsn} Bundle-RequiredExecutionEnvironment: J2SE-1.4,J2SE-1.5,JavaSE-1.6 Bundle-Version: ${version} Export-Package: com.ibm.db2.jcc,COM.ibm.*,sqlj.runtime,sqlj.runtime.*;version=${version} Import-Package: com.ibm.db2.jcc.licenses,java.sql*,javax.sql*,*;resolution:=optional Private-Package: * -classpath: db2jcc.jar -output: ${bsn}-${version}.jarMit den ersten beiden Zeilen definieren wir zwei Variablen, die wir intern verwenden, um uns die Arbeit etwas zu erleichtern. Die letzten beiden Zeilen werden durch ein Minus "-" eingeleitet und werden als entsprechende Option an das BND-Tool durchgereicht.
BND-Tool aufrufen
java -jar biz.aQute.bnd.jar db2jcc.bndDamit wird die Datei de.blogger.oli.com.ibm.db2jcc-3.53.70.jar erzeugt, die sich jetzt als Bundle in Felix oder anderen OSGi-Containern laden lässt. Wichtig beim Aufruf ist, dass die Steuer-Datei die Endung ".bnd" trägt.
Weitere Information zum Bau von Bundles findet sich z.B. unter
http://swik.net/Spring/Interface21+Team+Blog/Creating+OSGi+bundles/b2yoy
Zusammenfassung
Um aus einer normalen Jar-Datei ein OSGi-Bundle zu machen, sind folgende Schritte nötig:- biz.aQute.bnd.jar herunterladen
- .bnd-Datei erstellen (s. Beispiel db2jcc.bnd)
- Original-Jar wrappen: java -jar biz.aQute.bnd.jar db2jcc.bnd
... link (0 Kommentare) ... comment

- works stable
- is fun (not more)
- does not disturb you
... link (0 Kommentare) ... comment
Und darin liegt in meiner Einschätzung auch der große Vorteil des SOP-Ansatzes: die Datenbeschreibung erfolgt komplett mit Java-Mitteln. Damit reicht ein Blick in den Source-Code für die aktuelle Beschreibung. Klar geht das auch mit einer eigenen DSL und selbstgeschriebenem Generator, aber hier ist oft die Gefahr, dass man eigentlich Generator-Entwicklung macht (von Problemen mit dem Refactoring mal ganz zu schweigen).
Näheres zu SOP findet man über die Vortragsfolien des Workshops oder aber auch über soplets.org.
... link (0 Kommentare) ... comment

Trotzdem (oder vielleicht gerade deswegen) waren die Teilnehmer sehr zufrieden mit der Veranstaltung. Einzig die Frische des Raums in der Alten Scheuer wurde bemängelt. Der Workshop-Charakter (morgens Vortrag, mittags praktische Übungen) wurde dankbar aufgenommen, und jeder Teilnehmer konnte die Theorie vom Vormittag nachmittags ausprobieren (s. Bilder vom Workshop).
Da wir dieses Mal WLAN-Anschluss hatten, nahmen einige Teilnehmer dies zum Anlass, unter #sttt2011 zu twittern oder zu bloggen. Auch die Referenten nutzen das Internet für Aktualisierungen. So wurde noch während der Test-Tagen eine Mac-Version für den InspectIT-Client nachgereicht (www.inspectit.eu/downloads/) und die inspectIT-Demo aktualisiert.
Auswertung Fragebogen
Kriterium | sehr gut (1) | gut (2) | befr. (3) | (4) | (5) | Schnitt |
---|---|---|---|---|---|---|
Umfang | 7 | 6 | 1.46 | |||
Stoffvermittlung | 6 | 5 | 1.45 | |||
Lernklima | 11 | 2 | 1.15 | |||
Übungen | 6 | 3 | 2 | 1.64 | ||
Unterlagen | 2 | 7 | 2 | 2.00 | ||
Räumlichkeiten | 4 | 6 | 3 | 1.92 | ||
Gesamteindruck | 4 | 8 | 1.67 |
Was den Teilnehmern besonders gefiel
Ambiente, AtmosphäreAufteilung vormittags Vorträge, nachmittags Übungen
Überschaubarer Teilnehmerkreis
Gutes Konzept: Besser als reine Vorträge
Kleine Gruppen, angenehmes Klima
schön familiär
Viel Zeit für Workshops, intensives Arbeiten in kleinen Gruppen
Jubula, Bredex, Tag 2 war inhaltlich besser!
Systemtest nonstop
Die neue Workshopverteilung ist besser, da man ohne Streß die Übungen durchführen kann
Was den Teilnehmern nicht gefiel
Raumtemperatur zu kühl (mehrfach)Von den Übungen hätte ich am 1. Tage gerne mehr besucht
sehr toollastig
Großer Installations- und Setupaufwand bei den Übungen
Übungen zu kurz
keine Fragerunde direkt nach den Vorträgen, da die Zeit zu knapp war
Anreise mit Auto schwierig (parken)
Stühle könnten bequemer sein
FitNesse, Gebit
Zu oft Pizza
Fazit
Das positive Feedback, das wir von den Teilnehmern und Referenten bekommen haben, beweist, dass Testen nicht langweilig sein muss und ermutigt uns, die Test-Tage in zwei Jahren zu wiederholen - in wärmeren Räumen und zu einem konflikt-freieren Termin.... link (0 Kommentare) ... comment
Nähere Infos gibt es unter //jugs.org/tt2011/...
... link (0 Kommentare) ... comment

Since Eastern PatternTesting 1.1.0 is released. Some deprecated APIs from 0.8 and 0.9 are now removed, the check methods of the different JUnit testers are now renamed to assertXxx and the ClasspathMonitor has now a much faster startup time. For more infos about all changes see the release history.
The Wiki article "Testing with PatternTesting" explains how you can use the different annotations and testers which are provided for unit testing. If you want to practice it come to the Stuttgarter Test-Tage 2011 or try it yourself.Happy PatternTesting
... link (0 Kommentare) ... comment

This version is still based on Maven 2.2.1 and OpenOffice 3.2.1 but all the open points mentioned in my first article are fixed now. We use the maven-ooo-plugin to build an OOo extension for risk management (aOPM) and it works as expected.
What's next: the next step will be an update of the used libraries for Maven 3. A big problem for the near future is the fork of OpenOffice so at the moment I can't say if we will focus on OpenOffice 3.3 or LibreOffice.
... link (0 Kommentare) ... comment
For that reason there is a maven-inherit-plugin available, which allows you to extend non-local Maven plugins. You must add the OPS4J repository (as described on the maven-inherit-plugin page) and follow the steps of the usage page.
... link (0 Kommentare) ... comment
Ansonsten wünsche ich allen Lesern ein gutes neues Jahr, Stehvermögen bei den Vorsätzen und endlich das lang versprochene Java 7.

... link (0 Kommentare) ... comment