Apache Tomcat Team 2
Download the latest version here.
Projektdokumentation Team 2
Als Quellen haben wir meist StackOverflow und die jeweiligen offiziellen Dokumentation genutzt. StackOverflow war nützlich um allgemeine Konzepte zu verstehen und die Dokumentation um Details zu vertiefen.
An unseren ersten Aufgabe, das Erstellen eines make files für ein C Programm, war schwierig das es viele Möglichkeiten gibt um den Code erfolgreich zu bauen. Man muss jedoch sehr darauf achten das Code nur gebaut wird wenn Änderungen vorhanden sind, was vorallem in Kombination mit genutzten Headerfiles schwierig ist. Das Setup war einfach da die build essentials auf Linux vorinstalliert und konfiguriert sind. Ein Tipp ist den Build für alle möglichen Ausgangspunkte zu testen, also mit vorhandenem/fehlendem output folder und Änderung in Code/Header files. Bei dieser und unser nächsten Aufgabe war natürlich auch die antike Natur von make bzw ant, die sich in Dateistrukturen und Doku-Websites widerspiegelt, ein Hinderniss. Tomcat's Ant build hatte einige Probleme. Zum einen benötigt Tomcat eine relativ alte Java Version, die man bei parallelen Java Installation Ant unterschieben muss (export JAVA_HOME=[Java 8 Pfad]). Außerdem nutzte der Build Dependency Download Links die nicht gingen oder schlimmer: Manchmal nicht gingen. Der Rest des Build-Prozesses lief jedoch schmerzlos und man hatte schnell den eigenen Tomcat laufen. Als nächstes sollte die Architektur des Tomcat untersucht werden. Diese war zwar kaum Online dokumentiert aber die Aufgabe bestand ja sowieso darin selbst zu forschen. Schwierigkeiten gab es zum einen dadurch das Tomcat zu großenteilen dynamisch zur Laufzeit konfiguriert wird, indem verschiedene Klasse zusammen gepuzzelt werden, was im statischen Code kaum Nachvollziehbar war. Auch schwierig war das unklare Ziel der Aufgabe, hier wäre eine Beispiel Dokumentation und Leitfragen "Wie verarbeitet Tomcat Requests", "Welche(s) Design Pattern wird hier verwendet", etc. als Definition of Done hilfreich gewesen. Dieser Schritt hat uns jedoch sehr viel über den Aufbau Tomcats gezeigt, jedoch vorallem in der anschließenden gemeinsamen Besprechung. Außerdem hat man beim Erstellen der statischen Ansicht viel über bash/unix lernen können.
<== Maven, Jenkins Teil
Die Maven Multimodule pom.xml war durch ihre Einfachheit, ebenso wie die Integration des Tomcat-Engine Builds, keine große Herausforderung. Die Maven Builds für die mitgelieferten Webapps dagegen schon. Das lag vorallem daran das man sie mit komplett falscher Ordnerstruktur bauen kann, die Webapps dann jedoch in wenig hilfreichen Arten nicht funktionieren. Hier hat besonders die Dokumentation des WAR plugins geholfen, die die Ordnerstruktur gut darstellt. Man hätten sich nur direkt konsequent daran halten müssen. Durch die in der Dokumentationsaufgabe gelernten unix Befehle (find, sed) konnte man die Dateien auch meist ohne großen Aufwand in ihr neues Zuhause verpflanzen🌱. Das Ergebnis danach in einen Docker Image zu stecken war durch Docker-Vorerfahrung sehr einfach, auch die Jenkins Integration lief problemlos. Ein Tipp zum Schreiben des dockerfile ist hier das vorgegeben run.sh Skript als Referenz zu nutzen. Als nächste Aufgabe sollten verschiedene statische Analyse Werkzeuge in den Build Prozess integriert werden. Die integration in Maven war recht einfach da wichtige Schritte bereits im Assignment beschrieben waren. Die Integration in Jenkins war jedoch nicht so reibungslos. Die zugehörigen Plugins der Analysewerkzeuge hatten alle eine Warnung in deren Beschreibung: "This plugin reached end-of-life. All functionality has been integrated into the Warnings Next Generation Plugin.". Dieses Plugin war jedoch zum einen nur im Beta Repository verfügbar zum anderen war es dort aus gutem Grund weil es nicht funktioniert. Nachdem wir auf die "veralteten" Plugins umgestiegen sind funktionierte die Jenkins Integration. Die von den Werkzeugen gefundenen Fehler waren interessant und verständlich dargestellt. Um sie auch auf den eigenen Code anzuwenden erstellten wir eine weitere Jenkins Pipeline inklusive Jenkinsfile und fügten den Code als git Submodule hinzu. Dies hat den Vorteil das die Behobenen Fehler auch direkt in das Ursprungs-Repository fließen. In dem eigenen Code wurden jedoch kaum Fehler von den Tools gefunden. Dadurch waren sie bei der Refactoring Aufgabe nicht sehr hilfreich um Code Smells zu finden. Glücklicherweise hatte unsere eigener Code auch so genug. Am Refactoring war schwierig das der Code nicht durch Unit tests abgedeckt wurde und man erst ein anderes Refactoring machen musste um Unit tests zu schreiben. Das eigentliche Refactoring war dagegen einfach.