Im folgenden wird beschrieben, wie man sein Projekt so strukturieren kann, dass auf der einen Seite das Testen erleichtert wird, auf der anderen Seite die Tests vom produktiven Java Quellcode separiert werden. Das erleichtert zum Beispiel die Paketierung zur Auslieferung an Kunden, die lediglich den produktiven Quellcode erhalten sollen.

Bei einigen Entwicklungsumgebungen, wie z.B. Netbeans, ist bereits bei einem leeren Java Projekt eine Separierung von Test Quellcode und Java Quellcode vorgesehen: Es gibt einen Ordner für “Test Packages” und einen für “Source Packages”. Im Dateisystem werden diese auf die Ordner “src” und “test” entsprechend abgebildet. Bei der Tastenausführung werden aus beiden Verzeichnissen die Quellen übersetzt und die Ergebnisse zusammen geführt. Bei dem von Netbeans standardmäßig erstellten Buildfile kann man auch von der Kommandozeile mittels “ant test” die Tests ausführen, bei “ant jar” wird eine JAR Datei (im “dist” Verzeichnis) erstellt, die lediglich den produktiven Code enthält.

Durch das ant Buildfile und die Projektstruktur ist damit ein Netbeans Projekt von Haus aus direkt für eine Continuos Integration Umgebung optimal vorbereitet.

Eclipse ist noch nicht ganz soweit, jedoch sollte man seine Projektstruktur auch hier so aufbauen: Der Code ist klar getrennt, verwendet man eine parallele Paket Struktur, können auch Methoden die “protected” oder “default” Sichtbarkeit haben, einfach getestet werden. So vermeidet man zu grob geschnittene Tests (nur “public” Methoden testen) bzw. unnötige Erweiterung der Sichtbarkeit, in dem man Methoden “public” macht, nur um sie testen zu können.

Das ganze ist sehr einfach: Startet man ein neues Projekt, so kann man bei der Einrichtung direkt ueber “create new source folder” neben “src” einen “test” Source-Folder anlegen.

Eclipse fügt dann entsprechend alle übersetzten Class Dateien, in diesem Fall “Sample” aus den produktiven Sourcen und “SampleTest” aus den Test Quellen im “bin” Verzeichnis zusammen:

Bei Eclipse muss man sich noch selber um ein Build-System kümmern, wenn man von der IDE unabhängig bauen möchte – und das möchte man. Immer.

Hier bietet sich z.B. “Maven” an, welches für einfache Projekte auch schnell einzurichten ist. Alternativ kann man auch ant oder das neue Gradle benutzen. Übrigens: Möchte man von Anfang an seine Projektstruktur bereits entlang der Maven Konventionen aufbauen, sollte man seine produktiven Sourcen unter “src/main/java” und seine Test Klassen unter “src/test/java” anlegen. Setzt man kein Maven ein, macht das keinen großen Unterschied, da die IDE-Ansicht sich nicht unterscheidet. Moechte man jedoch auf Maven später umstellen, spart man sich etwas Arbeit und hat sich bereits an die Konventionen gewöhnt.

Weitere Artikel:

1. SwingDemo Projekt
2. Modular Java (Buch)
3. Java EE Summit Berlin

JPA, die Java Persistence API bietet im Vergleich zu JDBC ein erhöhtes Abstraktionsniveau und ermöglicht damit in kurzer Zeit Anwendungen zu entwickeln, in denen Daten dauerhaft gespeichert werden müssen.
Zum Hintergrund von JPA: Bei dem Umgang mit Datenbanken gibt es schon sehr lange JDBC (Java Database connectivity) als einheitliche API um die Verbindung zu Datenbanken herzustellen. Auch hier handelt es sich bereits um eine einheitliche Schnittstelle, jedoch wird darüber lediglich festgelegt, wie Verbindungen aufgebaut werden, wie eine Abfrage eingeleitet wird und wie Transaktionen manuell gesteuert werden können.
Damit bleiben zwei Probleme: Der SQL Code muss von Hand erstellt werden, was gerade bei CRUD (Create, Update, Delete) Anwendungen viel Produktivität kostet, und zudem ist der SQL Code in der Regel herstellerabhängig. Ein Wechsel von Oracle zu Postgres bedeutet damit das Programm an vielen Stellen ändern zu müssen. Auch sind händisch erstellte Abfragen nicht immer optimal: Lazy loading von Entitäten, Caching Strategien und Transaktionssteuerung können sehr aufwendig werden. Dazu gesellen sich der relativ hohe Wartungsaufwand und die Gefahr von Fehlern die erst zur Laufzeit entdeckt werden.Das Beispielprojekt wird ein einfaches Adressbuch, dabei werden Personen und ihre zugehörigen Adressen gespeichert. Im ersten Teil beschäftigen wir uns damit die Projektstruktur einzurichten, und die nötigen Bibliotheken zu installieren.

Dependencies

JPA selber ist lediglich eine API – diese wird durch einen sogenannten JPA Provider implementiert. Hibernate, OpenJPA und EclipseLink (bzw. Oracle Toplink) sind Beispiele fuer JPA Provider, die als OpenSource zur Verfuegung stehen und auch kommerziell verwendet werden koennen.
Am einfachsten lassen sich diese Abhaengigkeiten durch Maven erfuellen, Maven kuemmert sich dabei um Download der direkten und indirekten (transistiven) Dependencies. Fuer diejenigen, die bereits Maven Erfahrung haben und Maven mit JPA nutzen moechten, hier ein Beispiel (weiter unten findet sich ein fertiges Eclipse Projekt ohne Maven zum Download) fuer Hibernate als JPA Provider (und SLF4J zum Loggen):
<dependencies>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>3.3.2.GA</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-annotations</artifactId>
<version>3.4.0.GA</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-entitymanager</artifactId>
<version>3.4.0.GA</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-c3p0</artifactId>
<version>3.3.2.GA</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-ehcache</artifactId>
<version>3.3.2.GA</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-simple</artifactId>
<version>1.5.8</version>
</dependency>
<dependency>
<groupId>org.hsqldb</groupId>
<artifactId>hsqldb</artifactId>
<version>1.8.0.10</version>
</dependency>
</dependencies>

Manuelle Einrichtung

Hier eine Liste der nötigen Bibliotheken, für diejenigen, die von Hand (beinhaltet alle transitiven Abhängigkeiten) das Projekt konfigurieren möchten:

• antlr-2.7.6.jar
• c3p0-0.9.1.jar
• commons-collections-3.1.jar
• commons-logging-1.0.4.jar
• dom4j-1.6.1.jar
• ehcache-1.2.3.jar
• ejb3-persistence-1.0.2.GA.jar
• hibernate-annotations-3.4.0.GA.jar
• hibernate-c3p0-3.3.2.GA.jar
• hibernate-commons-annotations-3.1.0.GA.jar
• hibernate-core-3.3.2.GA.jar
• hibernate-ehcache-3.3.2.GA.jar
• hibernate-entitymanager-3.4.0.GA.jar
• hsqldb-1.8.0.10.jar
• javassist-3.4.GA.jar
• jta-1.1.jar
• slf4j-api-1.5.8.jar
• slf4j-simple-1.5.8.jar
• xml-apis-1.0.b2.jar

Diese JAR Dateien werden in den Classpath gelegt, normalerweise in einen “lib” Ordner, und anschließend wird der Classpath entsprechend konfiguriert. (In Eclipse über Rechtsklick auf das Projekt “Properties” im Menü auswählen, dann “Java Build Path” und dort mittels “Add JARs” die entsprechenden Dateien hinzufügen.)

JPA Projekt Download

Der Download als fertiges Eclipse Projekt (hier: Eclipse JPA Project) beinhaltet die nötigen JAR Dateien im “lib” Ordner, ist bereits entsprechend konfiguriert und benötigt kein Maven oder andere externe Tools.  (Die Ordnerstruktur verwendet jedoch die Maven Verzeichnisstruktur, was jedoch keine große Umstellung bedeuten sollte.)

Für dies Beispiel wird hsql als Datenbank verwendet, und dabei separat gestartet. Je nach Anwendung (Desktop oder Server) würde man in der Regel eine eingebettete Datenbank (Swing/Desktop Anwendung) oder eine externe Datenbank (Java Enterprise Application) verwenden. Hsql bietet den Betrieb als Embedded- und Standalone-Datenkbank an, dabei ist die JAR Datei mit rund 700kb relativ schlank und kann somit sehr gut für dieses Tutorial eingesetzt werden.

Um HSQL zu konfigurieren gibt es die Datei “server.properties”, die eine Datenbank konfiguriert, die in dem Ordner “db” abgelegt wird, “addressbook” heisst und auch als “addressbook” angesprochen wird.
Server properties:
server.database.0=db/addressbook
server.dbname.0=addressbook

Von der Kommandozeile startet man den HSQL Server dann aus dem Projekt Verzeichnis in dem sich der “db” Ordner, der “lib” Ordner mit der hsqldb JAR Datei  und die “server.properties” Datei befindet:
java -cp lib/hsqldb-1.8.0.10.jar org.hsqldb.Server

Damit ist die Vorbereitung der serverseitigen JPA Infrastruktur abgeschlossen, die nächsten Schritte beinhalten die Einrichtung von JPA Provider, Verbindung zur Datenbank und welche Java Klassen wie auf die Datenbank abgebildet werden sollen.
(Zum besseren Vergleich zwischen Hibernate und JPA beinhaltet das Beispielprojekt auch die entsprechende native Hibernate Konfiguration und die Hibernate API Aufrufe in separaten Klassen. Mehr dazu in den folgenden Artikeln.)

Weitere Artikel:

1. JPA Einführung: Entity Klassen
2. Java Testing best practice: Projekt Organisation

Maven reloaded ist das Thema der Präsentation von Jason van Zyl, die am 12.11.09 bei der Rheinjug durchgeführt wird.

Der Vortrag (in englisch) wird von Jason van Zyl, dem Gründer und CTO von Sonatype gehalten. Sonatype ist dabei die Firma, die Maven supported und das Apache Maven Projekt gegründet hat.Abstract: Maven 3.0 will be the version Maven for the people. The Maven team has gone to the ends of the earth to ensure backward compatibility, improve usability, increase performance, allow safe embedding, and pave the way for implement many highly demanded features. This talk will briefly cover the process and tooling changes that have occured in the Maven project in order to accomplish what we have done with Maven 3.0, as well as discuss the architectural and feature changes. Some of the process changes include setting up a multi-platform Hudson grid, building out a framework of over 440 integration tests, creating integration tests for all core Maven plugins, and systematically seeking out Maven 2.x OSS projects to validate Maven 3.x’s compatibility. We also built out a framework that measures disk I/O, network I/O, memory consumption, and CPU utilization to ensure that performance doesn’t degrade. The architectural changes that will be discussed will center around how POMs are constructed, how the lifecycle is executed, how the plugin manager executes, and how artifacts are resolved. Some features derived from these architectural changes include any-source POMs, versionless parent elements, a compositional form of Maven POM configuration we call mixins, lifecycle extension points, plugin extension points, and our new Jetty Client-based, single point of entry artifact resolution mechanism we call the repository system.