Communardo Techblog

Maven basierte Build-Prozesse haben sich in den letzten Jahren zunehmend zur Erzeugung der Entwicklungs- und Releasemodule etabliert. Neben dieser Aufgabe bieten sie auf sehr einfacheWeise die Möglichkeit, Reports (z.B. JUnit, PMD, u.a.) und Dokumentationen (Java Doc) der Softwaremodule zu erzeugen.

Vor allem die Checkstyle, PMD und FindBugs - Reports stellen wichtige Informationen bereit, die Aufschluss über die Qualität des Source Codes bieten. Letztendlich enthalten sie Richtlinien oder Wissen zu bestimmten Problemstellen im Source Code.

Da die Entwicklungszeiten in den Softwareprojekten knapp sind bleiben die per Nightly Build erzeugten Reports meist ungenutzt. Die manuelle Auswertung vor allem in der heißen Phase vor der Fertigstellung der Softwareprojekte wird meist aus Zeitgründen nicht mehr ausgeführt. So bleiben wichtige “Ratschläge” der Reports unberücksichtigt und potentielle Fehlerquellen werden mit in den Wirkbetrieb der Softwaremodule übernommen.

Um kontinuierlich von den Reports zu profitieren suchten wir nach einer Möglichkeit, die Ergebnisse der Reports automatisch zu berücksichtigen. Da bereits die technische Infrastruktur durch einen Continuous Integration Server vorhanden war und die Softwaremodule beim Einchecken durch die Entwickler gebaut wurden, lag die Unterbrechung des Builds im Fehlerfall am nächsten.

Und genau dafür bieten die genannten Maven Plugins (getestet mit Maven1) die Möglichkeit, den Buildprozess beim Auftreten von Fehlern zu unterbrechen.

PMD
maven.pmd.failonerror=true
maven.pmd.failonruleviolation=true

CheckStyle
maven.checkstyle.fail.on.violation=true

FindBugs
maven.findbugs.failOnError=true

Während man die Art der durchzuführenden Tests im Fall des PMD und FindBugs-Plugins sehr fein bestimmen kann, fehlt diese Abstufung im Falle des Checkstyle Plugins. In den kommenden Beiträgen wird mehr über die Konfiguration und die Möglichkeiten der Plugins zu lesen sein.

Beim Aufruf der Datenanalyse im Project Web Access kam auf einem neu installierten Rechner folgender Fehler:

“The query could not be processed: Safety settings on this machine prohibit accessing a data source on another domain”.

Zunächst etwas verwirrend, die Domäne war bei Server und Client eindeutig dieselbe. Ein Blick in die Sicherheitseinstellungen des Internet Explorer half. Hier sollte die URL des PWA in die Zone “Vertrauenswürdige Sites” aufgenommen werden. In Abhängigkeit der gewählten Standardstufe muss u.U. noch eine Einstellung vorgenommen werden:

Unter Verschiedenes > Auf Datenquellen über Domänengrenzen hinweg zugreifen entweder aktivieren oder bestätigen lassen.

Wählt man bestätigen, erscheint für Benutzer jedesmal beim Aufruf der Datenanalyse Website im Project Web Access folgender Hinweis:

Beim Firefox stellt sich die Problematik erst gar nicht, siehe aussagekräftige Fehlermeldung von Project Web Access:

Selbst in einer Windows Server 2003 Domäne sollte man darauf achten, dass der Anmeldename für MOSS Accounts nicht zu lang ist.

MOSS verwendet zur Anmeldung scheinbar den Prä-Windows 2000 Anmeldenamen und dieser hat maximal 20 Zeichen.

Darum nicht wundern, wenn zum Beispiel beim Starten der Dienste in der Zentraladministration hartnäckig die Meldung “Benutzername oder Kennwort falsch” erscheint und man sich sicher ist, alles richtig eingegeben zu haben.

In einem Blogeintrag vom 20. Juli 2007 habe ich bereits über diese Fehlermeldung berichtet und einen Lösungsweg aufgezeigt. In einem aktuellen Projekt trat der Fehler jedoch erneut auf, diesmal mit einer anderen Ursache.

Entwickelt wurde ein automatisch ablaufendener Workflow für den MOSS 2007, der manuell sofort oder mit festgelegter Startzeit gestartet werden werden konnte. Um den verzögerten Start zu realisieren wurde eine DelayActivity eingesetzt.

Eine erste prototypische Implementierung zeigte einen interessanten Effekt: Der Workflow funktionierte ohne Probleme, wenn er sofort gestartet wurde. Kam jedoch die DelayActivity für einen verzögerten Start zum Einsatz, wurde der Workflow-Status sofort auf “Beendet” gesetzt. Die Aktionen, die laut Workflow ausgeführt werden sollten, blieben unbeachtet. Eine Fehlermeldung fand sich nur nach intensiver Suche im Sharepoint-Log:

DehydrateInstance: System.Runtime.Serialization.SerializationException: End of Stream encountered before parsing was completed.

Trotzdem in diesem Workflow keine InfoPath-Dokumente verwendet wurden, gab die Exception den entscheidenen Hinweis: Es gibt ein Problem mit der Serialisierung. Anders als im vorangegangen Blogeintrag lag das Problem nicht bei der Serialisierung der Daten, die von einem Formular übergeben werden, sondern bei der Serialisierung des Workflows selbst. Eine Bereinigung bzw. Konvertierung der Attribute der Workflowklasse brachte letztlich den Erfolg. Hierzu sei anzumerken, dass besonders die Sharepoint-Klassen SP* in den meisten Fällen nicht serialisierbar sind.

Abschließend bleibt noch die Frage, warum der Fehler nur beim verzögerten Start des Workflows auftritt. Dies lässt sich mit der Grundfunktionalität der Windows Workflow Foundation erklären. Die in Sharepoint integrierte Workflow Runtime verwaltet alle Workflowinstanzen. Wird eine solche Instanz mittels einer DelayActivity angehalten, wird diese aus Speicher- und Performancegründen persistent ausgelagert. Für diese Auslagerung muss die Instanz natürlich serialisiert werden. Ohne die DelayActivity wird die Instanz im Speicher gehalten, bis der Workflow beendet wurde. Der Fehler tritt also nicht auf.

Standardmäßig lassen sich Mindmaps nicht direkt aus SharePoint Bibliotheken auschecken und editieren. Dafür gibt es aber eine freie Lösung direkt von Mindjet.

Dazu muss jeweils eine Erweiterung auf dem SharePoint Server und auf dem Client installiert werden. Dann können die Mindmaps direkt aus dem Kontextmenü geöffnet werden. Die Installationsdateien gibt es unter : http://mindjetlabs.com/cs/files/folders/mindjetlabs/rss.aspx?Tags=MOSS&AndTags=1

Über Project Web Access kann man die Eigenschaften eines Projektes ändern (Edit Project Properties). Hat man eine Eigenschaft geändert und klickt auf Save oder Save and Publish, so geschieht …. Nichts. Nur der Cancel Button funktioniert und verwirft brav alle Änderungen.

So … this is a known bug, wie in vielen Foren zu lesen ist. Warten wir also auf SP1.

Es gibt aber einen Workaround. Es müssen ALLE Felder geändert werden. Sprich, alle Felder auswählen und einfach die schon ausgewählten Werte anklicken bzw. wieder eintragen.

Dann funktioniert es. Umständlich, aber bis das SP1 dann mal da ist …

Da man ja sehr oft und sehr gerne auf virtuellen Maschinen entwickelt und auch zum Deployment nicht unbedingt ein paar hundert Kilometer reisen möchte, wird gerne zur Remote Desktop Verbindung gegriffen.

Dazu gibt es bei Unterwegs im Net eine ausführliche Beschreibung. Unter anderem die notwendigen Ports, damit man nicht an der Firewall des Kunden hängenbleibt.

Link: Unterwegs im Net