Oli's Blog

Last week there was the Java Forum Stuttgart with more than 1000 people, a lot of tweets and a lot of tips. One of the tip in a talk was TDGothi - the tamagotchi for TDD (Test Driven Design). Should I test it? Why not.

After installation I enabled it as fast view. Here my short result after 2 days working with it:

• works stable
• is fun (not more)
• does not disturb you

It does not make me a better developer. But it's fun and you need sometimes a little bit fun as developer.

Anfang Juni fand bei der JUGS ein Workshop zur Semantisch Orientierten Programmierung (SOP) statt. Die Kernidee dabei ist, dass die Datenbeschreibung mit Java-Hausmitteln erfolgt, nämlich Enumerations gekoppelt mit Annotations. Genau diesen Ansatz habe ich mit der Version 0.6 von gdv.xport ausprobiert und die Datenbeschreibung des GDV-Formats in die entsprechende Enumeration (z.B. Feld100) umgesetzt. Die Logik für den Umgang mit diesen Enumeration musste ich zwar selber schreiben, aber der große Vorteil dieses Ansatzes besteht darin, dass neue Satzarten sehr leicht von Außenstehende ergänzt werden können. Dies war mit der vorigen Version nicht so einfach möglich.

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.

Zwei Tage durften wir auf den Stuttgarter Test-Tagen 2011 das Thema "Testen" vertiefen, das ansonsten oft zu kurz kommt. Während es bei den letzten Test-Tagen über 40 Anmeldungen waren, waren es dieses Jahr leider nur 18 Stück - vermutlich eine Auswirkung der parallel stattfindenden JAX in Mainz.

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äre
Aufteilung 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.

Nach 2009 ist es wieder soweit - die Java User Group Stuttgart organisiert dieses Jahr zum zweiten Mal die Stuttgarter Test-Tage. Zwei Tage werden wir uns dort rund um das Thema "Testen" beschäftigen, das leider während des Studiums (und auch im Berufsleben) oft zu kurz kommt. Noch kann man sich zu den Test-Tagen anmelden, auch wenn die Anmeldefrist eigentlich schon vorüber ist.

Nähere Infos gibt es unter //jugs.org/tt2011/...

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

It is now a long time ago that I forked Frédéric's maven-ooo-plugin repository at github. Yesterday I finally finished version 1.1 and released it to labs/agentes.de/repository.

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.

For PatternTesting I wanted to inherit classes from the aspectj-maven-plugin but the parameters of the super class were not inialized by Plexus. Why? Because the javadoc tags are not accessible to Plexus.

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.

Und? Gute Vorsätze für's neue Jahr gefasst? Nein? Da hätte ich einen Vorschlag: reichen Sie doch einen Beitrag zu den Stuttgarter Testtagen ein.

Ansonsten wünsche ich allen Lesern ein gutes neues Jahr, Stehvermögen bei den Vorsätzen und endlich das lang versprochene Java 7.

This article has two goals:

• to report some news about the new maven-ooo-plugin-it project
• to give a short introduction how to start a project with a local GIT repository and push it later to github

Local GIT Repository Created

Yesterday I decided to start my own integration test project for the maven-ooo-plugin. Here are the steps to create a GIT repository for this project (GIT must be installed):

1. create the project directory (mkdir maven-ooo-plugin-it)
2. change to this directory (cd maven-ooo-plugin-it)
3. create local GIT repository (git init)

The other steps I did with Eclipse: I created a new project with the maven-ooo-plugin-it directory as new location and started the development. Later I called "Team > Share Project..." to connect the project to the local GIT repository and to commit my new files.

Pushed to GITHUB

Today I wanted to push this project to github. If you log and follow the Dashboard link you find a New Repository button which I used to create the maven-ooo-plugin-it repository on github. Now I got a list of steps which I followed:

1. cd cd maven-ooo-plugin-it
2. git remote add origin git@github.com:oboehm/maven-ooo-plugin-it.git
3. git push origin master

That's all.

The maven-ooo-plugin is now nearly working. mvn package generates now an OpenOffice plugin with .oxt suffix. But not always. It is hard to find the reason why the registration of the plugin can fail.

As I learned today one reason for an com.sun.star.deployment.DeploymentException can be:

• an incomplete classpath entry in the generated manifest file,
• a missing __writeRegistryServiceInfo or
• a missing __getComponentFactory method in a Java component

Unfortunately you get not really a hint form OpenOffice if the registration of a plugin fails. For more info you can read the OpenOffice forum.

Vor einigen Monaten hatten sich die DOAG (Deutsche Oracle Anwendergruppe) und verschiedene Java User Groups (darunter auch die JUGS in einem gemeinsamen Dachverband, der iJUG zusammengeschlossen. Ursprünglich war geplant, die Zeitschrift "Java aktuell" zum Java Forum Stuttgart rauszugeben - das hätte perfekt mit dem Vortrag "Pleiten, Pech und PatternTesting zusammengepasst, da genau zu diesem Thema auch ein entsprechender Artikel drin steht.

Na ja, jetzt sind es halt zwei Monate später. Aber wer Interesse daran hat, die Zeitschrift gibt es noch im gut sortierten Zeitschriftenladen...

Two objects which are equals should return the same hash code (and not the other way around, as some developers think).

...Note that it is generally necessary to override the hashCode method whenever this method is overridden, so as to maintain the general contract for the hashCode method, which states that equal objects must have equal hash codes.

This is corresponding Javadoc about the equals method. For those who forget this PatternTesting offers now an ObjectTester which checks classes with overwitten equals methods:

    ObjectTester.assertEquals(my.little.Dummy.class);

The ObjectTester will create with this call two Dummy objects to check the implementation. If it is not ok an Assertion Error will be thrown.

You can also add a package to check if all classes in the package have a correct equals/hashCode implementation:

    ObjectTester.assertEquals(Dummy.class.getPackage());
    ObjectTester.assertEqualsOfPackage("my.little");

Both calls are identical. You can also exclude classes from this check. This is sometimes necessary for classes where the constructor produces different objects (as is the case for the Date class, for example).

In a similar way you can check classes with the SerializableTester and CloneableTester if they are really serializable or clonable.

Oft steht man vor dem Problem, dass man ein bestehendes Projekt auf Maven umstellen will, ohne die Projekt-Struktur umzustellen. Das geht mit folgendem Eintrag in der POM:

<build>
  ...
  <sourceDirectory>${basedir}/src</sourceDirectory>
  <testSourceDirectory>${basedir}/test</testSourceDirectory>
  <resources>
    <resource>
      <directory>src</directory>
    </resource>
  </resources>
  <testResources>
    <testResource>
      <directory>test</directory>
    </testResource>
  </testResources>
  ...
</build>

In diesem Beispiel liegen die Sourcen unter src und die Test-Sourcen unter test (inkl. der jeweiligen Resource- und Property-Dateien).

Two weeks ago I started to automate the build process for an OpenOffice extension project (Java). I was happy to found a Maven plugin and a description on the OpenOffice wiki. But the last log entry on the CVS page says it: the development was started - that's all.

At github I found an enhancement of this Maven plugin. But the only stuff which was working on my MacBook was 'mvn archetype:create...'. Because I needed the plugin I forked it to my maven-ooo-plugin clone and tried to continue the work of Cédric and Frédéric.

What's working:

• mvn archetype:create (more or less, no changes from my side)
• mvn generate-sources (call of idlc, regmerge and javamaker, see OOo Java Eclipse Tutorial)

What does not work:

• mvn package (creation of OXT, the OpenOffice extension)

I have tested the plugin on MacOS and Linux, but not on Windows (I have no Windows computer). The next steps I plan is to begin with the .oxt creation and to look for a Maven repository where I can deliver it.