Die Versionsangaben in den Maven-Konfigurationen des checkerberry test centers beziehen sich nie auf feste Versionen, sondern geben immer die empfohlene Versionsnummer an. Wird das checkerberry test center in ein Maven-Projekt des Kunden eingebunden, können die Versionsnummern einfach in der Maven-Konfiguration überschrieben werden. Maven richtet sich bei der Auswahl der Versionsnummer an der Entfernung zum Wurzelprojekt, welches in diesem Beispiel das Kundenprojekt ist. Das bedeutet, dass die Definition der Versionen in den pom.xml Dateien des Kundenprojekts (Distanz 1) eine höhere Priorität haben, als die Versionen des checkerberry test center (Distanz 2). Dies liegt daran, dass die Maven-Konfigurationen des checkerberry test centers in dem Kundenprojekt lediglich referenziert werden.

Neben dem Standardverfahren von Maven zur Ermittlung der besten Version kann für jede externe Bibliothek die verwendete Versionsnummer geändert werden. Für alle externen Bibliotheken existiert eine Property, die den Wert der Version enthält. Das Property kann durch eine Konfiguration in der settings.xml überschrieben werden. Folgendes Code-Beispiel beschreibt die erforderliche Konfiguration der settings.xml.

…
<profiles>
  <profile>
    <activation>
      <activeByDefault>true</activeByDefault>
    </activation>
    <properties>
      <org.dbunit.checkerberry.version>2.4.7</org.dbunit.checkerberry.version>
    </properties>
  </profile>
</profiles>
…

Um ein Property in der settings.xml zu setzen, muss ein neues Profil angelegt werden. In dem angegebenen Code-Beispiel wird das Profil standardmäßig aktiviert (<activeByDefault>true</activeByDefault>). Dann wird die Versionsnummer von DbUnit auf den Wert 2.4.7 gesetzt. Diese Einstellung führt dazu, dass der in dem checkerberry test center konfigurierte Wert überschrieben wird.

Es ist darauf zu achten, dass die settings.xml immer dem aktuellen Benutzer zugeordnet ist. Daher muss diese Einstellung bei allen Nutzern angepasst werden. Dies betrifft insbesondere auch die Benutzer, unter deren Namen die Continuous Integration Systeme gestartet werden.

Das checkerberry test center verwendet slf4j [slf4j Homepage, 2013] als Logging-Api. Dadurch kann der Benutzer durch eine Bindung (z.B. slf4j-log4j12-1.7.5.jar) die konkrete Implementierung des Logging Frameworks wählen, z.B. Log4j [Log4j Homepage, 2010]. Das folgende Code-Beispiel enthält eine mögliche Konfiguration in Form einer log4j.properties Datei.

log4j.rootLogger=INFO, MyConsApp, MyFileApp
log4j.appender.MyConsApp=org.apache.log4j.ConsoleAppender
log4j.appender.MyConsApp.layout=org.apache.log4j.PatternLayout
log4j.appender.MyConsApp.layout.ConversionPattern=%d{ISO8601} %-5p [%t] %c:
%m%n

log4j.appender.MyFileApp=org.apache.log4j.DailyRollingFileAppender
log4j.appender.MyFileApp.datePattern='.'yyyy-MM-dd_HH-mm
log4j.appender.MyFileApp.file=checkerberry.log
log4j.appender.MyFileApp.layout=org.apache.log4j.PatternLayout
log4j.appender.MyFileApp.layout.ConversionPattern=%d{ISO8601} %-5p [%t] %c:
%m%n

log4j.logger.de.conceptpeople=DEBUG

Das Code-Beispiel enthält eine mögliche log4j-Konfiguration. Die Konfiguration aktiviert einen Appender, der die Ausgabe auf die Konsole steuert (MyConsApp). Des Weiteren wird ein Appender definiert, der Log-Informationen in die Datei checkerberry.log schreibt (MyFileApp).

Über den rootLogger wird der Standard-Log-Level definiert, der bei der Logging-Ausgabe berücksichtigt wird. In dem Beispiel werden nur Logging-Ausgaben auf INFO-Level und darüber ausgegeben. Als Ausnahme wird für alle Packages, die mit de.conceptpeople beginnen, der Log-Level auf DEBUG gesetzt.

Eine detaillierte Auflistung der Konfigurationsmöglichkeiten ist auf der Log4j-Homepage vorhanden.

mvn clean install -Djava.util.logging.conf.file=C:\settings\logging.properties

handlers=java.util.logging.ConsoleHandler

# Limit the message that are printed on the console to INFO and above.
java.util.logging.ConsoleHandler.level=INFO
java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter