Übungsaufgaben zum Paketieren mit jlink und jpackage

Kopiere den Text in ein KI-Sprachmodell Deiner Wahl und passe Kompetenzstufe, Anzahl, Bearbeitungszeit und Szenario bei Bedarf an. Wie die Aufgaben aufgebaut sind, beschreibt der Artikel Wie sind die Aufgaben aufgebaut?. Prüfe die Ergebnisse mit dem Lehrartikel: KI-Sprachmodelle machen Fehler.

Erstelle neue Übungsaufgaben zum Thema „Paketieren mit jlink und
jpackage“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/javafx-paketieren-jpackage
- https://oer-informatik.de/szenario-mitfahrlabor
- Stilbeispiel: https://oer-informatik.de/javafx-paketieren-jpackage-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- jlink
- jpackage
- Laufzeitabbild
- Installationspaket
- MSI
- DEB
- Pipeline-Artefakt
- GitLab CI
- Gradle
- Mitfahrgesuche

Kompetenzstufe: Kernkompetenz (alternativ: Basiskompetenz, Profilkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

1. je Zuordnung 1 Punkt:

2. je Aussage 1 Punkt (Entscheidung und Begründung):

1. Falsch: jpackage baut nur für das Betriebssystem, auf dem es läuft; ein MSI braucht einen Windows-Runner mit WiX.
2. Falsch: jlink nimmt nur die Wurzelmodule aus --add-modules und alles, was sie über requires brauchen; Module, die über Services geladen werden (z. B. jdk.localedata), muss man selbst angeben.
3. Richtig: Ohne gleichbleibende Upgrade-UUID hält Windows die neue Version für eine andere Anwendung und installiert sie daneben.
4. Falsch: Unter Windows signiert jpackage nicht; signiert wird danach mit Code-Signing-Zertifikat und signtool.

1. je Lücke 1 Punkt:

Eine Lösung, die --vendor oder --description zusätzlich setzt, ist ebenfalls richtig. Statt (5) ist auch --module-path mit dem Modulpfad möglich; dann ruft jpackage jlink selbst auf und jdk.localedata muss mit --add-modules an jpackage gehen. Das Ergebnis liegt im Ordner src/12-paketieren-jpackage/uebung-mitfahrgesuche.

2. 2 Punkte (je Menü-Zeile ein halber Punkt, Paketname 1 Punkt):

--linux-shortcut
--linux-menu-group Office
--linux-package-name mitfahrgesuche

3. 3 Punkte:

./gradlew installer -Ptyp=app-image                               # Programmordner ohne Installer
build/laufzeitabbild/bin/java --list-modules                      # muss jdk.localedata enthalten
build/installer/Mitfahrgesuche/bin/Mitfahrgesuche                 # Windows: build\installer\Mitfahrgesuche\Mitfahrgesuche.exe

Danach im Gesuch-Dialog den Kalender öffnen: Er muss deutsche Monats- und Tagesnamen zeigen.

4. 2 Punkte: jlink bricht ab, wenn der Ausgabeordner schon existiert; ohne Löschen würde jeder zweite Bau scheitern (1 Punkt). Beim Installer verhindert das Löschen, dass alte Pakete einer früheren Version im Ordner liegen bleiben und von der Pipeline mit eingesammelt werden (1 Punkt).

1. 7 Punkte: Stufe paket (1), needs (1), rules für den Hauptzweig (1), fakeroot installieren (1), Aufruf mit Typ und Adresse (1), Artefakt-Pfad passend zu --dest (1), Name und Aufbewahrung (1).

stages:
  - test
  - paket

gesuche-deb:
  stage: paket
  needs: [test]
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  script:
    - apt-get update && apt-get install -y --no-install-recommends fakeroot
    - chmod +x gradlew
    - ./gradlew installer -Ptyp=deb -Papi=http://mitfahrlabor.schule.example/v1 --no-daemon
  artifacts:
    name: "mitfahrgesuche-$CI_COMMIT_SHORT_SHA"
    expire_in: 14 days
    paths:
      - build/installer/*.deb

Die Adresse wirkt nur, wenn build.gradle.kts die Eigenschaft api wie im Artikel in --java-options "-Dmitfahrlabor.api=…" übernimmt. Die vollständige Datei liegt als .gitlab-ci.yml im Ordner der Beispiellösung.

2. 2 Punkte: jpackage baut nur für das Betriebssystem, auf dem es läuft; der Job läuft in einem Linux-Container (1 Punkt). Für ein MSI braucht es einen eigenen Job auf einem Windows-Runner (Auswahl über tags) mit JDK 25 und WiX Toolset, der gradlew.bat installer "-Ptyp=msi" aufruft und build/installer/*.msi als Artefakt ablegt (1 Punkt).

3. 2 Punkte: Der Pfad unter artifacts: paths passt nicht zum Zielordner von --dest (z. B. Tippfehler im Ordner oder in der Endung) (1 Punkt). GitLab bricht dann nicht ab, sondern schreibt beim Hochladen der Artefakte nur eine Warnung „no matching files“ ins Log (1 Punkt).

1. je Symptom 2 Punkte (Ursache 1, Korrektur 1):

• S1: Für MSI erlaubt Windows nur Versionsnummern aus Zahlen (Haupt-, Neben-, Build-Nummer); unter Linux nimmt jpackage -SNAPSHOT an, deshalb ist nur der Windows-Job rot. Korrektur: version = "1.0.0" und mit jeder Auslieferung erhöhen.
• S2: Die deutschen Sprachdaten stehen im Modul jdk.localedata, das über einen Service geladen wird und deshalb nicht im Modulgraphen auftaucht; ohne es fällt Java still auf englische Formate zurück. gradlew run nutzt das vollständige JDK. Korrektur: "--add-modules", "$hauptmodul,jdk.localedata" und "--include-locales", "de,en".
• S3: Der Artefakt-Pfad zeigt auf build/jpackage, das Paket liegt in build/installer; GitLab warnt nur („no matching files“). Korrektur: paths: - build/installer/*.deb.
• S4: Ohne -Papi=… schreibt der Build -Dmitfahrlabor.api=http://localhost:8080/v1 in die Konfigurationsdatei des Pakets. Die App liest zuerst die Systemeigenschaft, die Umgebungsvariable kommt nicht mehr zum Zug. Korrektur: im Job -Papi=http://mitfahrlabor.schule.example/v1 angeben (oder die Option im Paket ganz weglassen, wenn die Adresse über die Umgebungsvariable kommen soll).
• S5: Ohne feste --win-upgrade-uuid erzeugt jpackage bei jedem Bau eine neue Kennung; Windows hält 1.0.1 für eine andere Anwendung. Korrektur: einmal eine UUID erzeugen und als --win-upgrade-uuid <uuid> dauerhaft in jpackage/windows.txt eintragen; die alte Version einmalig von Hand entfernen.

2. 3 Punkte, zwei begründete Vorschläge (1,5 Punkte je Vorschlag), zum Beispiel:

• Regel für „Test“: Tickets mit Paket werden aus dem installierten Paket bzw. App-Image auf einem Rechner ohne JDK geprüft, nicht mit gradlew run.
• Pipeline-Schritt nach dem Paketbau: build/laufzeitabbild/bin/java --list-modules muss jdk.localedata enthalten, und die Datei Mitfahrgesuche.cfg im App-Image wird auf die erwartete Backend-Adresse geprüft (z. B. mit grep); ein Fehlschlag macht den Job rot.
• Ein Smoke-Test, der das App-Image headless startet und den Monatsnamen im Kalender prüft.

3. 3 Punkte: Für die Umkehr spricht, dass die Verwaltung die Adresse auf jedem Rechner ohne neues Paket ändern kann (1 Punkt). Dagegen spricht, dass eine vergessene oder alte Umgebungsvariable dann jede Einstellung aus dem Paket überstimmt und Fehler schwer zu finden sind; die übliche Rangfolge in Java-Anwendungen ist „Kommandozeile vor Umgebung“ (1 Punkt). Eine begründete Entscheidung, z. B.: Rangfolge lassen und keine Adresse ins Paket schreiben, wenn sie je Rechner verschieden sein soll; oder eine Konfigurationsdatei als eigenes Ticket (1 Punkt).