From 6298aff0520e45a56c31ab897170400ef9c2e62c Mon Sep 17 00:00:00 2001 From: "renovate[bot]" <29139614+renovate[bot]@users.noreply.github.com> Date: Mon, 27 Jul 2026 06:27:20 +0000 Subject: [PATCH 1/3] Bump dependency com.puppycrawl.tools:checkstyle to v13.9.0 --- pom.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pom.xml b/pom.xml index 8bfbf108..2640c463 100644 --- a/pom.xml +++ b/pom.xml @@ -84,7 +84,7 @@ 7.26.0 7.26.0-metrics 3.6.0 - 13.8.0 + 13.9.0 4.10.3.0 1.14.0 0.8.15 From e6823c18c4ddeb7f746c296ffff3bae067ff4d4d Mon Sep 17 00:00:00 2001 From: Ulli Hafner Date: Sun, 2 Aug 2026 17:54:35 +0200 Subject: [PATCH 2/3] Replace `JavadocStyle` with `SummaryJavadoc` --- etc/checkstyle-java-configuration.xml | 5 +---- etc/checkstyle-tests-configuration.xml | 5 +---- 2 files changed, 2 insertions(+), 8 deletions(-) diff --git a/etc/checkstyle-java-configuration.xml b/etc/checkstyle-java-configuration.xml index e0a68b22..a207a42c 100644 --- a/etc/checkstyle-java-configuration.xml +++ b/etc/checkstyle-java-configuration.xml @@ -41,10 +41,7 @@ - - - - + diff --git a/etc/checkstyle-tests-configuration.xml b/etc/checkstyle-tests-configuration.xml index 78ff1a73..f3653bed 100644 --- a/etc/checkstyle-tests-configuration.xml +++ b/etc/checkstyle-tests-configuration.xml @@ -41,10 +41,7 @@ - - - - + From 382ad7cc5d0530fd8bdc82fc51f75dfa689f80fc Mon Sep 17 00:00:00 2001 From: Ulli Hafner Date: Sun, 2 Aug 2026 18:00:01 +0200 Subject: [PATCH 3/3] Remove obsolete GitHub classroom documentation --- doc/Arbeiten-mit-GitHub-Classroom.md | 136 --------------------------- 1 file changed, 136 deletions(-) delete mode 100644 doc/Arbeiten-mit-GitHub-Classroom.md diff --git a/doc/Arbeiten-mit-GitHub-Classroom.md b/doc/Arbeiten-mit-GitHub-Classroom.md deleted file mode 100644 index 8d29c27d..00000000 --- a/doc/Arbeiten-mit-GitHub-Classroom.md +++ /dev/null @@ -1,136 +0,0 @@ -Disclaimer: Die folgende Anleitung ist unter großer Hilfe der folgenden beiden Tutorials entstanden: -- [How To Create a Pull Request on GitHub](https://www.digitalocean.com/community/tutorials/how-to-create-a-pull-request-on-github) -- [GitHub Standard Fork & Pull Request Workflow](https://gist.github.com/Chaser324/ce0505fbed06b947d962) - -# Arbeiten mit GitHub Classroom - -Für Abgaben zu allen meinen Veranstaltungen benutze ich aktuell GitHub Classroom: GitHub Classroom bietet Studierenden **und** Lehrenden eine einfache Möglichkeit, Aufgaben für Praktika in einem Git Projekt zu verwalten. Die Nutzung bietet folgende Vorteile: -- Sie lernen die gleiche Arbeitsweise kennen, die auch in der Industrie und vielen Open-Source-Projekten verwendet wird. So sind Sie ideal auf die Praxis vorbereitet. Ich nutze beispielsweise GitHub seit mehr als 10 Jahren für meine [Jenkins Open Source Plugins](https://plugins.jenkins.io/ui/search?query=uhafner). -- Sie haben eine ausgereifte Oberfläche, mit der Sie Ihre Abgaben verwalten können: - - Darstellung von Commits - - Reviews von Pull Requests - - Nachverfolgung von offenen Punkten und Fehlern - - Automatische Builds - - Automatische Sicherung durch Backups -- Ich habe eine einfache Möglichkeit, private Repositories auf Basis eines Templates für Abgaben zu erstellen. Die Aufgaben können sowohl als Einzel- oder Teamaufgabe konzipiert sein. Die Steuerung der Berechtigungen erfolgt automatisch. - -Eine Voraussetzung zur Nutzung von GitHub in unserer Veranstaltung ist das Anlegen eines entsprechenden [Accounts](https://github.com/signup?source=login). Haben Sie bereits einen GitHub Account, können Sie diesen gerne weiter verwenden. - -Anschließend treten Sie den einzelnen Classrooms bei, indem Sie ein von mir jeweils versendetes bzw. in Moodle hinterlegtes Link auswählen. I.A. erstelle ich pro Abgabe einen eigenen Classroom. In fortgeschrittenen Semestern gibt es aber auch Classrooms, die über mehrere Abgaben verwendet werden. - -Über jeden Classroom bekommen Sie (oder Ihr Team) dann ein eigenes Git Repository, indem Sie alle Dateien (Dokumente, Programmtexte, etc.) Ihrer Abgaben hinzufügen. Im ersten Semester können Sie zum Hochladen die GitHub Oberfläche nutzen. Je erfahrener Sie werden, umso schneller können Sie den direkten Zugang über die Versionsverwaltung Git nutzen, das macht dann vieles einfacher und komfortabler. - -Wenn Sie weitere Fragen zu GitHub Classroom haben, nutzen Sie bitte auch die [Online Hilfe](https://classroom.github.com/help). Fragen können Sie auch direkt im Praktikum (oder im jeweiligen RocketChat Kanal der Veranstaltung) stellen. In den nachfolgenden Abschnitten sind die wichtigsten Punkte kurz zusammengefasst. - -## Im Classroom einem Assignment beitreten - -Der erste Schritt für eine Abgabe ist der Beitritt zum entsprechenden Classroom. Dazu müssen Sie das von mir versendete Link anklicken und bestätigen. Wenn Sie noch keinen GitHub Account haben, ist das jetzt die Gelegenheit. Nach dem Beitritt in den Classroom müssen Sie zunächst Ihren Namen aus der Liste der vorhandenen Namen auswählen. Damit helfen Sie mir hinterher bei der Zuordnung von Hochschul- zu GitHub-Account. Die Namen habe ich aus dem ZPA exportiert, wenn Sie sich nicht finden geben Sie mir bitte Bescheid (Sie können trotzdem schon beginnen). - -Ist die Aufgabenstellung eine Teamaufgabe, dann müssen Sie sich Ihrem Team zuordnen. Dazu treten Sie entweder dem bereits von einem andern Teammitglied erstellten Team bei. Falls noch kein dementsprechendes Team existiert, können Sie selbst es neu anlegen. Sprechen Sie sich bitte vorher ab, wer das Team erstellt, sonst haben wir hinterher zu viele Teams. - -Als letzten Schritt müssen Sie dem Beitritt mit *Accept* bestätigen. Dann wird automatisch ein neues Repository angelegt und mit meinem Template gefüllt. - -## Mit dem Repository arbeiten - -Damit die Aufgaben bewertet werden können, müssen Sie Ihren Quelltext in das GitHub Repository hochladen. Git ist ein [verteiltes Versionsmanagement System](https://git-scm.com/book/de/v2/Verteiltes-Git-Verteilter-Arbeitsablauf), d.h. Sie finden eine Kopie dieses Repositories (neben dem Original auf GitHub) auf Ihrem Rechner und auf den Rechnern Ihrer Teammitglieder. - -### Über die Entwicklungsumgebung das Projekt verwalten - -Am einfachsten nutzen Sie nur die Entwicklungsumgebung IntelliJ, um Ihr Projekt mit GitHub zu synchronisieren. - -#### Import mit der Entwicklungsumgebung - -Nach dem Start der Entwicklungsumgebung haben Sie die Möglichkeit, Ihr Projekt direkt zu importieren: Mit der Aktion **Get from VCS** (im Startup Wizard) oder dem Menüpunkt **File->New->Project from Version Control...** lässt sich das GitHub Projekt automatisch nach IntelliJ importieren. IntelliJ kümmert sich ab dann automatisch über die Verbindung zu GitHub. Kopieren Sie dazu Ihr Repository Link aus dem Classroom im Dialog in das Feld **Repository URL->URL** und bestätigen Sie den Import mit **Clone**. Beachten Sie, dass Sie sich beim Import über HTTPS authentifizieren müssen. Dazu müssen Sie ein Token in GitHub erzeugen, die Authentifizierung via Browser funktioniert aktuell nicht. - -Nachdem das Projekt auf Ihren Rechner übertragen wurde, wird es in IntelliJ importiert und gebaut. Je nach bestehender Konfiguration müssen Sie dazu noch im Konfigurationsdialog **File->Project Structure->SDKs** ein JDK 17 unter dem Namen "17" anlegen und referenzieren. Ist das erledigt, können Sie die Tests in Ihrem Projekt starten. Dazu können Sie auf das Projekt mit Rechts klicken und **Run All Tests** auswählen. In den meisten Classroom Projekten habe ich noch eine spezielle **All Tests** Run-Konfiguration angelegt, die Sie auch direkt nutzen können. - -#### Hochladen von Änderungen - -Nach Veränderung Ihrer Dateien, werden diese farblich in IntelliJ markiert. Mit dem Kommando **Git->Commit** spielen Sie -Ihre Änderungen zurück nach GitHub. Geben Sie im dann im neuen Dialog eine Commitbeschreibung ein (was haben Sie geändert) -und bestätigen Sie den Dialog mit **Commit and Push**. IntelliJ führt dann einen lokalen **Commit** aus und speichert Ihre -Änderung im Git Repository **lokal**. Damit die Änderungen auch in GitHub sichtbar werden, wird anschließend Ihr -komplettes Repository nach GitHub übertragen. - -### Mit der Kommandozeile arbeiten - -Alternativ können Sie für diese Schritte auch die Kommandozeile nutzen. Dazu sind die in den nachfolgenden Abschnitten beschriebenen Schritte erforderlich. - -#### Das Repository auf den eigenen Rechner holen - -Zunächst müssen Sie das Repository auf den eigenen Rechner holen. Git ist ein [verteiltes Versionsmanagement System](https://git-scm.com/book/de/v2/Verteiltes-Git-Verteilter-Arbeitsablauf), d.h. Sie finden eine Kopie dieses Repositories (neben dem Original auf GitHub) auf Ihrem Rechner und auf den Rechnern Ihrer Teampartner. Diese Kopie kann mit folgendem Kommando auf den eigenen Rechner geholt werden: - -```shell -# Clone your repository to your local machine using SSH -git clone git@github.com:hafner-hm-edu/PROJECT.git -``` - -Falls noch kein [SSH Schlüssel auf GitHub](https://docs.github.com/en/free-pro-team@latest/github/authenticating-to-github/adding-a-new-ssh-key-to-your-github-account) hinterlegt ist, lässt sich das alternativ auch mit HTTPS erledigen: - -```shell -# Clone your repository to your local machine using HTTPS -git clone https://github.com/hafner-hm-edu/PROJECT.git -``` - -Für die einfache passwort-freie Nutzung von GitHub empfehle ich die [Einrichtung von SSH](https://help.github.com/en/github/authenticating-to-github/connecting-to-github-with-ssh) möglichst schnell nachzuholen. - -Eine weitere Alternative ist die GitHub Console, siehe dazu auch die [Online Hilfe](https://cli.github.com). - -### Eigene Änderungen entwickeln - -Für jede Abgabe (und für jede noch so kleine Änderung am Projekt), **muss** ein neuer Branch angelegt werden. -Die direkte Arbeit auf dem `main` Branch ist nicht sinnvoll und daher verboten. - -Um einen Branch anzulegen, sind folgende Schritte nötig: - -```shell -# Checkout the main branch - you want your new branch to come from main -git checkout main - -# Create a new branch named newfeature (give your branch its own simple informative name) -git branch newfeature - -# Switch to your new branch -git checkout newfeature -``` - -Nun geht es ans Editieren bzw. Programmieren und alle Änderungen werden Schritt für Schritt erstellt. Hier hat sich das Test Driven Development bewährt, doch das soll nicht Teil dieser Anleitung sein (siehe [Kapitel Testen](Testen.md) in meinen Kodierungsrichtlinien). - -Eine weitere sinnvolle Vorgehensweise ist das schrittweise Entwickeln: Die Entwicklung wird nicht in einem Rutsch durchgeführt und dann mit einem Commit abgeschlossen, sondern in mehreren Iterationen. Jeder Schritt, der fehlerfrei übersetzt werden kann und bei dem danach alle Tests durchlaufen, sollte einzeln mit einem Commit abgeschlossen werden. Dann lassen sich die Änderungen hinterher besser nachvollziehen. - -Beim Commit ist noch wichtig, eine gute Commit-Message zu vergeben, Chris Beam hat hierzu den hilfreichen Artikel [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/) geschrieben, der dies gut erklärt. Das muss nicht so formal sein, wie dort beschrieben, hier sehen Sie einige Beispiele in meinem Projekt [codingstyle](https://github.com/uhafner/codingstyle/commits/main). - -Je nach Aufgabenstellung gibt es im Projekt eine [GitHub Action](https://docs.github.com/en/free-pro-team@latest/actions), die das Projekt nach jedem Commit neu baut und überprüft. Siehe dazu auch das [Kapitel Continuous Integration](Continuous-Integration.md) bzw. [Autograding](Autograding.md). - -## Pull Request vorbereiten und stellen - -Sobald alle Änderungen lokal mit einem Commit abgeschlossen wurden, können diese in das GitHub Projekt integriert werden. Dazu ist lediglich ein Push erforderlich: - -```shell -# Push the local branch newfeature to a remote branch in the forked repository (using the same name) -git push --set-upstream origin newfeature -``` - -Nun sind diese Änderungen auch Online im eigenen GitHub Projekt sichtbar. GitHub erkennt dort automatisch, dass ein neuer Branch angelegt wurde und bietet eine entsprechende Schaltfläche in der Oberfläche an. Alternativ kann auch über den [Pull Request Dialog](https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request) ein neuer Pull Request angelegt werden. - -Beim Anlegen des Pull Request muss nun ein Titel und eine Beschreibung eingegeben werden. Der Titel sollte den Namen der Aufgabe enthalten, die Beschreibung ggf. weitere Details dazu. Verwenden von Anrede, Grußformel oder Schlussformel sind nicht sinnvoll. - -Noch ein Hinweis in eigener Sache: Bitte weisen Sie den Pull Request **niemals** mir zu. Ebenso bitte **keine Review Wünsche** an mich eintragen, bei mehr als 50 Teilnehmern pro Vorlesung und vielen Abgaben pro Semester wird es sonst schnell unübersichtlich. Ich bewerte Ihre Abgaben automatisch nach Ablauf der Abgabefrist. Das kann je nach Teilnehmerzahl auch einmal dauern. - -**Vor** dem finalen Anlegen des Pull Request muss geprüft werden, ob der Pull Request die gewünschten Änderungen enthält - und auch nur diese! Dazu den Abschnitt Files im Dialog öffnen und die einzelnen Änderungen durchgehen. Tauchen dort Änderungen auf, die nichts mit der Abgabe zu tun haben, so sind diese zu entfernen. Typischerweise sind dies Umformatierungen oder Leerzeilenänderungen an nicht beteiligten Abschnitten oder gar komplett andere Dateien (z.B. aus der Entwicklungsumgebung). - -Um solche Änderungen zu entfernen und damit den Pull Request zu säubern, müssen diese mit dem bereits beschriebenen Workflow umgesetzt werden: im Editor die Änderungen an den entsprechenden Dateien vornehmen, Commit lokal ausführen und dann wieder mit Push auf das GitHub Projekt bringen. - -Schaut der Pull Request dann wie gewünscht aus, so kann er mit *Create* erzeugt werden. Falls Sie noch nicht sicher sind, ob dieser PR fertig ist, können Sie diesen auch zunächst als *Draft* erstellen. Dann ist mir (und den Teammitgliedern) klar, dass der PR noch in Arbeit ist und kein abschließendes Feedback erwartet. - -### Den Pull Request aktualisieren - -Sobald der Pull Request erzeugt wurde, wird dieser i.A. mit verschiedenen Tools automatisch überprüft. Welche Tools zum Tragen kommen, hängt individuell vom Projekt ab. Typischerweise wird eine [Continuous Integration](Continuous-Integration.md) gestartet, die einen Entwicklungs-Lebenszyklus ausführt: - -1. Compile -2. Test -3. Analyze - -Jeder dieser Schritte wird in GitHub mit einem *Ok* oder *Failed* Status markiert, ggf. auch über -[GitHub Checks](https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/about-status-checks). Ist einer der Schritte mit *Failed* markiert, muss der Pull Request überarbeitet werden. Dazu muss der Fehler analysiert werden und dann der Quelltext an den passenden Stellen aktualisiert werden, sei es bei Compile- oder Testfehlern, bei Unterschreitung der geforderten Testabdeckung oder bei Verstößen gegen die Kodierungsrichtlinien. -Details dazu finden sich im Abschnitt [Autograding](Autograding.md).