13.10.2012

Maven Build Profiles - Test unterschiedlicher JPA Provider

Für einen zukünftigen Vortrag habe ich mir mir heute die unterschiedlichen JPA Provider etwas genauer angeschaut.
Auf dem Plan standen, neben Hibernate, EclipseLink oder auch OpenJPA.


Um für die Betrachtung eine möglichst schnell zu wechselnde Laufzeitumgebung zu haben, habe ich mir die Maven Build Profiles mal wieder ins Gedächtnis gerufen. Ziel der Build Profiles ist es ja, dass man recht leicht zwischen dedizierten Umgebungen wechseln kann. Gleichzeitig kann man in den Build-Profilen aber auch selektiv Dependencies oder Properties überschreiben, setzen oder neu definieren. Also eigentlich genau das richtig für mein Unterfangen, oder?

Begonnen habe ich mit einer einfachen Entität, dem Standard-Beispiel quasi. Basis für die gesamte Betrachtung war eine einfache Person mit ein paar wenigen Attributen.


Eine einfache und leicht zu verstehende Entität. Um die Provider möglichst einfach zu testen, habe ich einen kleinen JUnit-Test erstellt. Dieser versucht eine Person zu erstellen, diese zu persistieren und schlussendlich auch wieder aus der Datenbank zu lesen.


Der Test selbst ist unspektakulär, der EntityManager wird vor jedem Test erstellt und es wird eine Transaktion geöffnet. Nach jedem Test wird der EntityManager wieder geschlossen. Interessant ist allerdings noch die Erzeugung der EntityManagerFactory. Dies wird vor dem Test selbst in der @BeforeClass Methode ausgeführt und sieht wie folgt aus:


Der Name der Persistence-Unit wird an dieser Stelle aus einer System-Property ausgelesen. Je nach Provider wird eine der drei Persistence-Units für die Erzeugung der EntityManagerFactoryherangezogen.

Damit diese Property vom Buildprozess aus gesteuert werden kann, wird das Surefire-Plugin um einen Konfigurationseintrag erweitert.


Mit Hilfe dieser Property können nun die Build Profiles elegant die Werte überschreiben und damit die zugehörige Persistence-Unit für den Test auswählen.


Durch diese Konfiguration kann für jeden Provider ein eigenständiges Profil erstellt werden, welches, von den anderen Profilen unabhängig, eigene Dependencies definiert und vollkommen autark aufgerufen werden kann. Damit ist ein Wechsel des Providers bereits während der Testphase möglich.


Ein Aufruf von mvn clean test -P EclipseLink liefert dann direkt die folgende Ausgabe.


In beiden Fällen wird die Auswahl der Persistence-Unit über die überschriebene Property getätigt. Die Dependencies und sonstigen Einstellungen werden ebenfalls aus dem aktivierten Profil entnommen.

Der Code ist wie immer im Repository verfügbar.