This is not because continuum lacks memory, but because maven does – and running findbugs is a quite resource-hungry undertaking.
The following addition to the “mvn” executable (residing in your maven’s “bin” folder) should do (tested in the 2.0.8 release):

MAVEN_OPTS="-Xmx1024m -Xms128m -XX:MaxPermSize=512m".

I must admit that -Xmx1024m is rather generous, though. 256m or 512m might do for many cases, too.


org.apache.maven.continuum.execution.ContinuumBuildCancelledException: The build was cancelled

at org.apache.maven.continuum.execution.AbstractBuildExecutor.executeShellCommand(AbstractBuildExecutor.java:214)
at org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.build(MavenTwoBuildExecutor.java:138)
at org.apache.maven.continuum.core.action.ExecuteBuilderContinuumAction.execute(ExecuteBuilderContinuumAction.java:118)
at org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:408)
at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:147)
at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:50)
at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116)
at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442)
at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:987)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:528)
at java.lang.Thread.run(Thread.java:619)
Caused by: org.codehaus.plexus.util.cli.CommandLineException: Error while executing external command, process killed.
at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:164)
at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:89)
at org.apache.maven.continuum.utils.shell.DefaultShellCommandHelper.executeShellCommand(DefaultShellCommandHelper.java:114)
at org.apache.maven.continuum.utils.shell.DefaultShellCommandHelper.executeShellCommand(DefaultShellCommandHelper.java:59)
at org.apache.maven.continuum.execution.AbstractBuildExecutor.executeShellCommand(AbstractBuildExecutor.java:202)
... 11 more
Caused by: java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at java.lang.UNIXProcess.waitFor(UNIXProcess.java:165)
at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:128)
... 15 more


The simple reason is: The build is taking longer than continuum allows it to take, and thus the execution is canceled.
The maximum amount of time a build may take is schedule-specific, and can thus be configured in the “schedules” view under “Administration”.

If you change the execution time, i would recommend to adapt the time between checks for new builds accordingly.

Here’s a screenshot showing the setting that worked for my maven project:

Unfortunately, such a setting usually does not contain a username, since this has to be provided by the actual team member connecting to version control.
Neither did i have any intention to configure a placeholder into the scm section, forcing the developers to mess with the maven settings.xml in order to provide their own username.

Luckily, after searching a while, i found a proper solution.
SSH allows an optional per-host specific username setting to be placed in a file called “config” located in the user’s .ssh directory, for example

File: ~/.ssh/config


Host my.host.name
User myusername


Thanks to Chad Humphries for posting the Solution on programming is hard.
It really wasn’t…

2.1: Voraussetzungen

• Continuum ist erfolgreich aufgesetzt
• Es existiert bereits ein maven2-Projekt
• Das bestehende maven2-Projekt ist unter Versionskontrolle (Vorzugsweise subversion)

2.2: <scm>-Konfiguration der POM.xml überprüfen

Da sich continuum einige essentielle Informationen aus der primären pom.xml beschafft, muss der <scm> Eintrag auf jeden Fall vorhanden sein.
Hier ein Beispiel, wie die <scm>-Sektion für svn+ssh konfiguriert ist, wenn sich die developer-connection, connection und url nicht unterscheiden (was oft der Fall ist):

	<scm>
		<connection>
			scm:svn:svn+ssh://hostname/[repository-URL]/[Ordner mit primärer pom.xml]
		</connection>
		<developerConnection>
			scm:svn:svn+ssh://hostname/[repository-URL]/[Ordner mit primärer pom.xml]
		</developerConnection>
		<tag>HEAD</tag>
		<url>
			scm:svn:svn+ssh://hostname/[repository-URL]/[Ordner mit primärer pom.xml]
		</url>
	</scm>

Wichtig, ist, dass die Einträge mit scm:svn: beginnen; Nur so kann continuum die korrekte “Provider” – Klasse für den Zugriff auf das Repository bestimmen.

Des weiteren würde ich empfehlen, auch die ...-Sektion in der pom gefüllt zu haben, da die dort enthaltenen Developer ebenfalls in die Konfiguration des continuum-Projektes einfliessen.

2.3: Build-Profil in continuum anlegen

Continuum erlaubt es sinnvollerweise, die JAVA und maven-Versionen in Profilen zu speichern und diese den Builds zuzuweisen.
Vor dem Anlegen eines Projektes empfiehlt es sich also, ein Profil Anzulegen.

Dazu werden zunächst die vorhandenen JAVA und maven-Versionen (und ggf. weitere Tools) unter “Installations” hinzugefügt.
Hier ein Beispiel mit java 1.6 und maven 2.0.8:

Eine Auswahl dieser Installations lässt sich dann als Profil zusammenfassen:

2.4: Maven 2-Projekt importieren

Ist die pom richtig konfiguriert und ein Profil vorhanden, lässt sich unter “Add Project” > “Add Maven2.x Project” ein Dialog zum Hinzufügen einer pom öffnen.
Continuum unterscheidet dabei zwischen zwei unterschiedlichen Fällen:

• Zugriff auf eine pom.xml per http(s)
• Zugriff auf eine pom.xml per upload (nur single-module pom’s)

Wichtig ist dabei, dass Continuum diese pom.xml nur ein einziges mal, nämlich zum Anlegen des Projektes benötigt (später wird automatisch die pom.xml aus dem konfigurierten SCM-Repository verwendet).
Hat man kein Multi-Module Projekt, so empfiehlt sich die “Upload” Funktion.
Ansonsten muss die pom.xml und die dazugehörigen Unterverzeichnisse und pom’s über http(s) verfügbar sein.
Man kann also nicht ein scm: …. URL in das Eingabefeld eintragen, sondern (leider) nur eine http/https URL.

Das ist kein Problem, wenn man Subversion (empfehlenswerter Weise) über Apache per https verfügbar gemacht hat.
In meinem Fall war das nicht möglich, da das Universitäts-SVN nur per “svn+ssh” verfügbar ist.
Ich habe also das maven-Projekt (Ohne Sourcecode, nur die pom’s und Verzeichnisse) auf einen x-beliebigen Webserver geschoben und einfach die entsprechende http-URL verwendet.
Da diese nur einmal benötigt wird, ist das kein grosses Problem.

Continuum konfiguriert und installiert nun das Projekt automatisch und legt es unter der in der pom spezifizierten Gruppe an, in meinem Falle wie folgt:

2.4.1: Anpassen der Projekt-Build Konfiguration

Hat man ein multi-module Projekt, so werden die Module durch continuum per default nicht rekursiv, sondern einzeln gebaut (maven-Option --non-recursive).
Das kann Probleme geben, wenn man relative Pfade in seiner Konfiguration verwendet hat (beliebt bspw: “../src/config/…..”). Am einfachsten ist es, lediglich das primär-Projekt bestehen zu lassen und das rekursive Bauen durch Entfernen der –non-recursive-Option wieder zu aktivieren.

Das in 2.3 konfigurierte Profil kann im Projekt ausgewählt werden, ebenso wie ein Schedule.
Schedules können unter “Administration” angelegt werden und sind nichts weiter als eine einfache CRON-Einträge mit dem aus Unix bekannten Format. Ein Projekt mit eigenem Profil und Schedule sieht dann etwa so aus:

2.4.2: Notifications

Benachrichtigungen über Build-Vorgänge können in der pom.xml oder direkt in Continuum konfiguriert werden. Continuum 1.1 unterstützt dabei mail, irc, jabber, MSN und Wagon als Benachrichtigungstypen.

Am naheliegendsten dürfte wohl eine Benachrichtigung per E-Mail sein.

Hat man seine in der pom konfiguriert, so hat jeder Developer eine eindeutige , welche man für die Konfiguration von Benachrichtigungen in folgender Weise in der pom.xml nutzt:

<ciManagement>
<system>continuum</system>
<url>[continuum-url]</url>
<notifiers>
    <notifier>
      <type>mail</type>
      <configuration>
        <address>developer-id</address>
      </configuration>
    </notifier>
    </notifier>
    ... [weitere notifier] ...
</notifiers>
</ciManagement>

Statt der Developer-id kann auch eine E-Mail Adresse verwendet werden.

Alternativ lassen sich auch weitere Benachrichtigungen in der Projekt-Sicht von Continuum hinzufügen.

Wichtig beim Versand der E-Mails ist die richtige E-Mail Konfiguration von continuum (1.4: Konfiguration verbessern). Insbesondere sollte die absender-Adresse den korrekten Hostnamen des continuum-Servers beinhalten, da die Mails sonst leicht als SPAM klassifiziert werden.

Referenzen & Literaturempfehlungen

• Apache Continuum
  Homepage des Apache-Continuum Projektes
• Apache Maven
  Homepage des Apache-Maven Projektes
• Kontinuierlich zum Ziel – Eine Einführung in Maven Continuum
  JavaMagazin 07/2007
  Autor: Dr. Halil-Cem Gürsoy
  Knappe Einführung in continuum, bietet aber eine gute Ãœbersicht
• Continuous Integration with Continuum
  Java.net
  Autor: John Ferguson Smart
  Umfangreiches Howto aus dem Jahr 2006, was noch ein paar Andere Aspekte zeigt als mein Post.

Hin und wieder ist man in der Universität mit der vergnüglichen Tatsache konfrontiert, dass es weder eine brauchbare vorhandene Anzahl an Entwicklungswerkzeugen gibt, noch dass sich irgend jemand – ausserhalb von Lehrveranstaltungen – um Prozesse in der Softwareentwicklung kümmert.

Sprich: Ein Projekt soll umgesetzt werden, und außer einem SVN-Account gibt’s nichts.

Bei einem Team von 8 Leuten ist das völlig unzureichend. Neben einem ordentlichen Issue tracking bin ich auch daran gewöhnt, mittels eines Continous Integration-Systems aktuelle Buildstände abzurufen und den Stand der Dinge im Auge behalten zu können. Von einem ordentlichen WIKI zur Projektdoku ganz zu schweigen.

Da der Code an sich mittels Maven2 verwaltet wird, hatte ich sofort continuum ins Auge gefasst – schließlich ist continuum selbst Java-basiert und speziell für maven – Projekte entwickelt.

1.1: Voraussetzungen

Da Continuum eine J2EE-Webapplikation ist, muss zunächst einmal ein entsprechender Servletcontainer her.
Im recht schwachbrüstigen WIKI werden Resin, JBOSS, tomcat und glassfish als Referenzen angeführt.
Da ich mich gut mit Tomcat auskenne entschloss ich mich, continuum mit diesem zu installieren. als JDK entschied ich mich für Sun’s JDK 1.6.3, Datenbank sollte nicht die integrierte Derby, sondern ein vorhandenes MYSQL werden.

1.2: Die richtige Distribution herunterladen

Auf der continuum-Downloadseite stehen unterschiedliche Arten des 1.1-Releases zur Verfügung:
Die etwas schräge standalone-Distribution (Warum sollte man so etwas benutzen, wo es ein schönes, Standardkonformes WAR-Deployment gibt?), und die webapp-Distribution.
Ich empfehle in jedem Fall letztere zu verwenden, da somit kein Herumgefrickel in irgendwelchen Scripten notwendig wird.

1.3: continuum deployen und konfigurieren

1.3.1: Tomcat installieren

Der gute Tomcat lässt sich sehr einfach installieren. Ist das JDK vorhanden muss lediglich die Umgebungsvariable JAVA_HOME gesetzt sein.
Dann reicht es, wenn man keine weiteren Anpassungen braucht, die tomcat 6 core-distribution herunterzuladen und zu entpacken. Unix-typisch sind unter bin/ die ausführbaren Dateien, sprich start-Scripts (auch das weiter unten erwähnte catalina.sh – Script).
Unter conf/ findet man die server.xml, in welcher man die unten angeführten Anpassungen für die mysql-Anbindung durchführen kann.

1.3.2: continuum-Parameter in Umgebungsvariablen

Aus einem mir unklaren Grund brauch die continuum-webapp zwei JVM-Parameter um sich “zu orientieren”:
appserver.home und appserver.base sollten entsprechend auf das CATALINA_HOME und CATALINA_BASE Verzeichnis zeigen.
Bei einer sauberen default- Installation sind diese Verzeichnisse identisch. Ich habe das durch einen Eintrag am Anfang der catalina.sh erledigt:

export CATALINA_OPTS="-Dappserver.home=$CATALINA_HOME -Dappserver.base=$CATALINA_HOME"

1.3.3: MYSQL anbinden

Out-Of-The-Box verwendet Continuum Derby als Datenbank. Da ich MYSQL verwenden wollte war es notwendig, eigene DataSource-Konfigurationen vorzunehmen.
DataSources können Global oder Kontext-spezifisch in Tomcat Konfiguriert werden. Ich entschied mich, sie im <Context> Element der server.xml zu konfigurieren:

<Context path="/continuum" docBase="continuum">
<Resource name="jdbc/users"
            auth="Container"
            type="javax.sql.DataSource"
            username="..."
            password="..."
            driverClassName="com.mysql.jdbc.Driver"
            url="jdbc:mysql://localhost/...?autoReconnect=true" />

  <Resource name="jdbc/continuum"
            auth="Container"
            type="javax.sql.DataSource"
            username="..."
            password="..."
            driverClassName="com.mysql.jdbc.Driver"
            url="jdbc:mysql://localhost/...?autoReconnect=true" />

  <Resource name="mail/Session"
            auth="Container"
            type="javax.mail.Session"
            mail.smtp.host="localhost"/>
</Context>

Dazu muss der passende mysql-connector natürlich im lib-Verzeichnis des Tomcats platziert werden. (Bei 5′er Tomcats unter common/lib, ab 6 einfach “lib”).
Wichtig ist, dass der Datenbanknutzer Tabellen etc. anlegen darf. Zudem ist bei der Anbindung von continuum an MYSQL oft folgende Fehlermeldung zu sehen:


Error thrown executing CREATE TABLE '.....'
...
com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Specified key was too long; max key length is 765 bytes


Das Problem existiert, da Continuum PRIMARY KEY-Constraints über mehrere varchar-Felder (als composite primary key) verwendet und tritt auf, wenn für
das Encoding der für continuum verwendeten Datenbank ein Encoding gewählt wurde, wass mehr als ein Byte pro Character verwendet – Beispielsweise “utf8_general_ci”.
Ich habe aus diesem Grund ein latin1-Encoding verwendet – Danach lief alles glatt.

1.3.4: Richtiges ablegen der .war-Datei

Extrem wichtig ist, dass Verzeichnis der continuum webapp unter “webapps” genau so zu nennen wie den Contextnamen:

<Context path="/continuum" docBase="continuum">

Da es ansonsten zu unangenehmen Fehlern bei der Auflösung der konfigurierten Datasource kommt.
Das continuum….war-File sollte also unter “webapps” am besten als “continuum.war” gespeichert werden.

1.3.5: Start!

Mit diesen Einstellungen sollte die Continuum webapp starten. Der Startvorgang wird recht ausführlich im logs-verzeichnis von catalina protokolliert.

1.4: Konfiguration verbessern

Die Out-Of-The-Box Konfiguration hat noch ein paar Defizite, welche in der application.xml der ausgepackten .war-Datei verbessert werden können.
Diese findet sich unter …/webapps/continuum/WEb-INF/classes/META-INF/plexus.

Unter

    <!--
    | The mail notifier
    |-->
    <component>
      <role>org.codehaus.plexus.notification.notifier.Notifier</role>
      <role-hint>mail</role-hint>
      <implementation>org.apache.maven.continuum.notification.mail.MailContinuumNotifier</implementation>
    ...

Sollte beispielsweise die sender-mailbox konfiguriert werden, da continuum sonst als continuum@localhost Nachrichten per SMTP versendet:

    <configuration>
        <from-mailbox>continuum@myhost.domain</from-mailbox>
        <from-name>Continuum Server</from-name>

1.5: Problem mit Jsch beheben

In der mit Continuum ausgelieferten Version enthält die java secure channel-Blibliothek Noch einen Nullpointer-Fehler, der sich
allerdings erst dann zeigt, wenn tatsächlich ein build in continuum durchgeführt wird. Dann erscheint folgendes im build-log:


...
java.lang.NullPointerException
at com.jcraft.jsch.ChannelSession.run(Unknown Source)
...


Zum Beheben einfach das jsch….jar File aus dem WEB-INF/lib Verzeichnes der continuum webapp mit einer aktuelleren Version, in meinem Fall jsch-0.1.36.jar, ersetzen.

Weiter geht es in Maven2-Projekt in Continuum konfigurieren.