Java Musterlösung (kurz jml) ist ein kleines Skript mit dem mehrere Projektversionen aus einer Musterlösung generiert werden können.
jml wurde ursprünglich für Java-Projekte entwickelt, kann aber durch diverse Optionen auch für andere Projekte genutzt werden.
Zur Differenzierung im Informatikunterricht erstelle ich gerne mehrere Projektversionen mit mehr oder weniger Hilfestellungen, um dem Leistungsstand der Schülerinnen und Schüler besser gerecht zu werden. Inklusive einer Musterlösung können so schnell drei bis vier Projektversionen entstehen, die parallel weiterentwickelt werden müssen.
Befindet sich ein Fehler im Code, sollen die Aufgaben angepasst werden oder hat sich einfach ein Rechtschreibfehler in einen Kommentar eingeschlichen, müssen alle Projektversionen angepasst werden. Dabei habe ich schnell mal eine Version vergessen oder einen neuen Fehler eingebaut.
Vor einigen Jahren habe ich den Prozess mit jml vereinfacht. Das Skript generiert aus einer Basisversion, die mit Markierungen für Aufgaben und Lösungen versehen ist, die verschiedenen Projektversionen, die für den Unterricht nötig sind. Anpassungen sind nur noch im Basisprojekt notwendig.
Beispiele zur Verwendung finden sich in meinen Projekt-Repository und den dazugehörigen Projektversionen.
Die Installation wird wie gewohnt mit pip durchgeführt:
$ pip3 install jmlBei erfolgreicher Installation ist nun das jml Kommando verfügbar.
$ jml --version
jml, version 0.3.6jml benötigt Python 3.8 oder neuer.
jml kann auch ohne pip einfach als Skriptdatei genutzt werden. Es werden keine externen Abhängigkeiten genutzt. Dazu die aktuelle Version der Datei jml.py aus dem Repository kopieren und auf der Festplatte speichern. Das Skript kann dann mit Python 3 ausgeführt werden:
$ python3 jml.py --version
jml, version 0.3.6jml benötigt im einfachsten Fall den Pfad des Basisprojektes und den Pfad des Ausgabeordners:
$ jml pfad/zum/Basisprojekt --out pfad/zum/ausgabeordnerNach Ausführung befinden sich in pfad/zum/ausgabeordner die Musterlösung und die Projektversionen.
Die Inhalte und Anzahl an Versionen werden durch die Inhalte der Dateien im Basisprojekt bestimmt.
Angenommen in Basisprojekt liegt eine Datei mit dem Namen Beispiel.java mit folgendem Inhalt:
class Beispiel {
/*aufg*
// TODO: Erstelle eine Objektvariable "zahl" vom Typ int
*aufg*/
//ml*
private int zahl;
//*ml
public int add( int pAndereZahl ) {
/*aufg*
// TODO: Gib die Summe aus der Objektvariablen "zahl" und "pAndereZahl" zurück.
return 0;
*aufg*/
//ml*
return zahl + pAndereZahl;
//*ml
}
}Dann erzeugt jml diese Ordnerstruktur in pfad/zum/ausgabeordner:
pfad/zum/ausgabeordner/
├── Basisprojekt/
│ └── Beispiel.java
└── Basisprojekt_ML/
└── Beispiel.java
Inhalt von Basisprojekt_ML/Beispiel.java:
class Beispiel {
private int zahl;
public int add( int pAndereZahl ) {
return zahl + pAndereZahl;
}
}Inhalt von Basisprojekt/Beispiel.java:
class Beispiel {
// TODO: Erstelle eine Objektvariable "zahl" vom Typ int
public int add( int pAndereZahl ) {
// TODO: Gib die Summe aus der Objektvariablen "zahl" und "pAndereZahl" zurück.
return 0;
}
}Als Standard wird wie oben nur die Projektversion 0 erstellt. jml kann aber auch mehrere Projekte erstellen, wenn die Aufgaben-Markierungen mit einer entsprechenden Nummer versehen werden.
Angenommen die Beispiel.java von oben sieht so aus:
class Beispiel {
/*aufg*
// TODO: Erstelle eine Objektvariable "zahl" vom Typ int
*aufg*/
//ml*
private int zahl;
//*ml
public int add( int pAndereZahl ) {
/*aufg*
// TODO: Gib die Summe aus der Objektvariablen "zahl" und "pSummand" zurück.
return 0;
*aufg*/
//ml*
return zahl + pAndereZahl;
//*ml
}
/*aufg* 2
public int sub( int pAndereZahl ) {
// TODO: Gib die Differenz aus der Objektvariablen "zahl" und "pSummand" zurück.
return 0;
}
*aufg*/
}Dann werden statt der Version 0 die Projektversionen 1 und 2 erzeugt, da im zweiten Aufgaben-Marker eine konkrete Versionsnummer angegeben wurde:
pfad/zum/ausgabeordner/
├── Basisprojekt_1/
│ └── Beispiel.java
├── Basisprojekt_2/
│ └── Beispiel.java
└── Basisprojekt_ML/
└── Beispiel.java
Es ist auch möglich eine Markierung für mehrere Projektversionen zu nutzen:
/*aufg* >1
// Taucht nur in Projektversionen nach Version 1 auf.
*aufg*/
/*aufg* !=2
// Taucht in allen Projektversionen außer 2 auf.
*aufg*/
/*aufg* <=2
// Taucht nur in Projektversionen 1 und 2 auf.
*aufg*/Seit Version 0.3.4 ist es möglich, auch einem Lösungs-Tag eine Versionsnummer wie für Aufgaben zu geben. Dadurch wird der Inhalt zusätzlich zur Musterlösung auch in den spezifizierten Aufgabenversionen gesetzt:
//ml* >1
// Taucht in der Musterlösung und Versionen größer 1 auf
//*mlDie Funktion von jml ist durch eine Vielzahl von Optionen anpassbar. Die Optionen können als Kommandozeilen-Argumente übergeben, oder in Konfigurationsdateien gespeichert werden.
Eine Übersicht der verfügbaren Kommandozeilen-Argumente ist mit -h abrufbar
$ jml -hAlle Optionen (und noch eine Handvoll mehr) lassen sich auch in einer von mehreren Konfigurationsdateien festlegen. jml sucht dazu bei jedem Start nach .jml Dateien im Basisprojekt, im Wurzelverzeichnis (--project-root) und im Home-Ordner des angemeldeten Nutzers (~/.jml).
Die Konfigurationen werden dann in umgekehrter Reihenfolge geladen, die Einstellungen im Basisprojekt haben also die höchste Priorität. Sie werden nur noch von Kommandozeilen-Argumente überschrieben.
Für das Beispiel oben könnte der Aufbau so aussehen:
~/ ├── .jml ├── pfad/zur/wurzel/ │ ├── .jml │ └── Basisprojekt/ │ ├── .jml │ └── Beispiel.java └── pfad/zum/ausgabeordner
Inhalt von ~/.jml:
[settings]
task open=/*<aufgabe>
task close=</aufgabe>*/
solution open=//<loesung>
solution close=//</loesung>Inhalt von ~/pfad/zur/wurzel/.jml:
[settings]
zip = yes
ml suffix = Loesung
name format = {project}-{version}
include = *.java,*.txtInhalt von ~/pfad/zur/wurzel/Basisprojekt/.jml:
[settings]
task open=/*aufgabe*
task close=*aufgabe*/
encoding = iso-8859-1
name = MaeusekampfDer Aufruf von jml sieht dann so aus:
$ jml --project-root "~/pfad/zur/wurzel" "~/pfad/zur/wurzel/Basisprojekt" --out "pfad/zum/ausgabeordner"jml lädt nun zunächst ~/.jml und setzt die Start- und Endmarkierungen auf eine XML-Variante.
Danach wird ~/pfad/zur/wurzel/.jml geladen, da dies per --project-root Argument als Wurzelverzeichnis gesetzt wurde. Für diese Projektgruppe werden ZIP-Dateien der Projektversionen erzeugt, außerdem wird das Suffix für die Musterlösung von ML auf Loesung geändert. Das Format der Projektnamen wird angepasst (_ durch - ersetzt) und es werden auch .txt Dateien nach den Aufgaben- und Lösungs-Markierungen durchsucht.
Als drittes wird ~/pfad/zur/wurzel/Basisprojekt/.jml geladen. Hier werden speziell für dieses eine Projekt die Aufgaben-Marker erneut verändert und die Datei-Codierung auf iso-8859-1 (statt utf-8) festgelegt. Schließlich wird noch der Projektname auf Maeusekampf festgelgt, anstatt den Ordnernamen Basisprojekt zu verwenden.
Die Ausgabe sieht dann so aus (sofern die Aufgaben- und Lösungs-Markierungen in Beispiel.java angepasst wurden):
~/
├── .jml
├── pfad/zur/wurzel/
│ ├── .jml
│ └── Basisprojekt/
│ ├── .jml
│ └── Beispiel.java
└── pfad/zum/ausgabeordner/
├── Maeusekampf-Loesung/
│ └── Beispiel.java
├── Maeusekampf-1/
│ └── Beispiel.java
├── Maeusekampf-2/
│ └── Beispiel.java
├── Maeusekampf-Loesung.zip
├── Maeusekampf-1.zip
└── Maeusekampf-2.zip
Die Tabelle zeigt eine Übersicht aller Optionen, die in einer Konfigurationsdatei oder per Kommandozeilen-Argument gesetzt werden können.
| Optionsname in Konfigurationsdateien | Kommandozeilen-Argument | Beschreibung |
|---|---|---|
| output dir | -o / --out | Legt den Zielordner für die Ausgabe der Projektversionen fest. Beachte, dass der finale Ausgabeordner unterhalb von outdir abhängig von --project-root noch variieren kann. |
| name | -n / --name | Setzt den Namen der erstellten Projektversionen. Im Namensformat wird {project} durch den Namen ersetzt. Als Standard wird der Ordnername des Basisprojektes verwendet. |
| name format | --name-format | Legt das Format fest, nach dem die Projektversionen benannt werden. Der Wert ist ein Python-Formatierungsstring und kann die Variablen {project} für den Namen, {version} für die Versionsnummer und {date} für das aktuelle Datum enthalten. Auf diese Weise können Projekte beispielsweise mit einer Jahreszahl versehen werden (name format = {date:%Y}_{project}-v{version}). Standard ist {project}_{version}. |
| task open | -to / --tag-open | Setzt die Anfangsmarkierung für Aufgaben. Die Markierung sollte nach einem öffnenden Block-Kommentar stehen, damit die Aufgabenstellung in der Basisversion auskommentiert ist. Standard ist /*aufg*. |
| task close | -tc / --tag-close | Setzt die Endmarkierung für Aufgaben. Die Markierung sollte vor einem schließenden Block-Kommentar stehen, damit die Aufgabenstellung in der Basisversion auskommentiert ist. Standard ist *aufg*/. |
| task comment prefix | Diese Option erlaubt die Modifikation der Zeilen in einer Aufgabe. Wenn die Option auf eine Zeichenkette gesetzt wird, wird in jeder Zeile in einer Aufgabe das erste vorkommen der Zeichenkette entfernt. Auf diese Weise können Aufgaben auch für Programmiersprachen, die keine Blockkommentare unterstützen, aaskommentiert werden. task comment prefix = # würde zum Beispiel Zeilenkommentare in Python entfernen. Beginnt die Zeichenkette allerdings mit einem /, dann wird in den fortgeschrittenen Modus geschaltet. Hier wird direkt ein regulärer Ausdruck und eine Ersetzung angegeben. Dazu muss der Wert das Format /regex/replace/ haben. / muss durch \/ maskiert werden. In jeder Zeile wird dann regex durch replace ersetzt. Details sind in der Python Dokumentation zu regulären Ausdrücken zu finden. |
|
| solution open | -mlo / --ml-open | Setzt die Anfangsmarkierung für Lösungen. Die Markierung sollte nach einem Zeilen-Kommentar stehen, damit die Musterlösung in der Basisversion lauffähig bleibt. Standard ist /ml*. |
| solution close | -mlc / --ml-close | Setzt die Endmarkierung für Lösungen. Die Markierung sollte nach einem Zeilen-Kommentar stehen, damit die Musterlösung in der Basisversion lauffähig bleibt. Standard ist //*ml. |
| solution comment prefix | Wie task comment prefix für Lösungen. |
|
| solution suffix | -mls / --ml-suffix | Setzt die Versionsnummer der Musterlösung. Standard ist ML. |
| clear | --no-clear | Verhindert, dass die Ordner der Projektversionen zuerst vollständig gelöscht werden. Vorhandene Dateien werden dann überschrieben, aber Dateien, die nicht im Basisprojekt sind (oder in den Excludes stehen) werden nicht berührt und verbleiben in den Projektversionen. |
| project root | --project-root | Setzt das Wurzelverzeichnis, anhand dessen die Ordnerstruktur im Zielordner festgelegt wird. Das Verzeichnis sollte ein Elternverzeichnis des Basisprojektes sein. Im Wurzelverzeichnis wird außerdem nach einer .jml Datei gesucht, die vor der Konfigurationsdatei im Basisprojekt geladen wird. |
| include | -i / --include | Setzt die Liste der Suchmuster für Dateien, in denen nach Aufgaben- und Lösungs-Markierungen gesucht werden soll. Standard ist *.java. |
| +include | Auftauchen und ergänzt die Liste der Includes um weitere Suchmuster, anstatt sie zu ersetzen. | |
| -include | Auftauchen und entfernt Suchmuster aus der Liste der Includes. | |
| exclude | -e / --exclude | Setzt die Liste der Suchmuster für Dateien, die komplett ignoriert werden soll. Diese Dateien tauchen nicht in den Projektverisonen auf. Excludes haben Vorrang vor Includes. Standard ist *.class,*.ctxt,.DS_Store,Thumbs.db,.vscode,.eclipse,*.iml. |
| +exclude | Ergänzt die Liste der Excludes um weitere Suchmuster, anstatt sie zu ersetzen. | |
| -exclude | Entfernt Suchmuster aus der Liste der Excludes. | |
| additional files | Eine Liste von Dateien, die zusätzlich in alle Projektversionen kopiert werden sollen. Die Dateien werden nicht nach Markierungen durchsucht und exakt kopiert. | |
| +additional files | Ergänzt die Liste der zusätzlichen Dateien um weitere Dateien, anstatt sie zu ersetzen. | |
| -additional files | Entfernt Dateien aus der Liste der zusätzlichen Dateien. | |
| -v / --versions | Liste von Versionsnummern von Projektversionen, die erstellt werden sollen. Bezieht sich nicht auf die Musterlösung. Diese kann mit --delete-ml abgestellt werden. |
|
| encoding | --encoding | Zeichenkodierung der Dateien. Standard ist utf-8. |
| delete empty files | --delete-empty | Wenn gesetzt werden Dateien, die nach dem kompilieren keinen Inhalt mehr haben, nicht in die Projektversionen kopiert. |
| create zip | -z / --zip | Erstellt zu jeder Projektversion zusätzlich eine ZIP-Datei mit demselben Namen. |
| create zip only | Erstellt nur die ZIP-Dateien. Impliziert create zip = yes. |
|
| creat zip dir | Ausgabeverzeichnis für die ZIP-Dateien, falls dieses von OUT abweicht. Standard ist dasselbe Verzeichnis wie für die Ausgabe der Projektversionen. (Also OUT bzw. ein Unterverzeichnis von OUT, wenn ein Wurzelverzeichnis angegeben wurde.) | |
| delete solution | --no-ml | Löscht die Musterlösung nach Ablauf des Programms. Unabhängig von dieser Einstellung wird die Musterlösung immer als erstes erstellt, um in den Dateien nach Aufgaben-Markierungen zu suchen und so die zu erstellenden Projektversionen zu ermitteln. Diese Einstellung löscht den Ordner der Musterlösung aber danach wieder. Es wird dann auch keine ZIP-Datei mehr erstellt. |
| --debug | Schaltet die Debug-Ausgaben ein. | |
| --dry-run | Schaltet den Debug-Modus ein und gibt alle Änderungen auf der Konsole aus. Es werden aber keine Ordner und Dateien erstellt. Mit dieser Option kann vor der Ausführung geprüft werden, ob die Konfiguration korrekt ist. |
Das folgende Beispiel kopiert die .class Dateien mit in die Projektversionen und ignoriert dafür einige ausgewählte .java Quelltexte. Dies kann sinnvoll sein, wenn das Projekt einige vordefinierte Klassen enthält (zum Beispiel eine fertige GUI), die von den Schüler:innen aber nicht bearbeitet werden sollen.
~/
├── wurzel/verzeichnis/
│ ├── .jml
│ ├── files/
│ │ ├── .gitignore
│ │ └── package.bluej
│ └── Basisprojekt/
│ └── .jml
└── ausgabe/ordner
Inhalt von ~/wurzel/verzeichnis/.jml:
[settings]
output dir = ~/ausgabe/ordner
task open = /*<aufg>
task close = </aufg>*/
solution open = //<ml>
solution close = //</ml>
name format = {project}-v{version}
create zip only = yes
additional files = ~/wurzel/verzeichnis/files/.gitignore,
~/wurzel/verzeichnis/files/package.bluejInhalt von ~/wurzel/verzeichnis/Basisprojekt/.jml:
project root = ~/wurzel/verzeichnis
+exclude = MyMailGUI.java,MyMailSettingsGUI.java
-exclude = *.classMit diesen Einstellungen kann jml zum Beispiel auch für ein HTML-Projekt genutzt werden:
~/
├── wurzel/verzeichnis/
│ ├── files/
│ │ ├── .gitignore
│ │ └── package.bluej
│ └── Basisprojekt/
│ │ ├── .jml
│ └── index.html
└── ausgabe/ordner
Inhalt von ~/wurzel/verzeichnis/Basisprojekt/.jml:
[settings]
task open = <!--aufg
task close = /aufg-->
solution open = <!--ml-->
solution close = <!--/ml-->
include = *.html,*.htmEinige Programmiersprachen (wie Python oder TeX) besitzen keine
Block-, sondern nur Zeilenkommentare. Für diese Fälle gibt es die
Optionen task comment prefix und solution comment prefix,
mit denen eine Zeichenkette festgelegt werden kann, die am Anfang
jeder Zeile entfernt wird.
~/
├── wurzel/verzeichnis/
│ ├── files/
│ │ ├── .gitignore
│ │ └── package.bluej
│ └── Basisprojekt/
│ │ ├── .jml
│ └── beispiel.py
└── ausgabe/ordner
Inhalt von ~/wurzel/verzeichnis/Basisprojekt/.jml:
[settings]
task open = # aufgb:
task close = # aufg
task comment prefix = #
solution open = # ml:
solution close = # ml
include = *.pyMarkdown-Dokumente besitzen in der Original-Syntax keine Kommentare, daher werden die Markierungen im Basisprojekt angezeigt. Auch die Aufgabenstellungen lassen sich dann nicht verstecken. Ansonsten funktioniert ˋjmlˋ ohne weiteres auch mit Markdown-Dateien.
Wird die Markdown-Datei in HTML konvertiert, dann wird nach Konverter werden aber auch HTML-Kommentare interpretiert und in der Ausgabe versteckt. Daher könnte dieselbe Konfiguration wie oben verwendet werden.
Das Beispiel zeigt eine Konfiguration, um aus einer Markdown-Datei zwei Arbeitsblätter mit Rechenaufgaben zu generieren.
[settings]
task open = <!--aufg
task close = /aufg-->
solution open = <!--ml-->
solution close = <!--/ml-->
include = *.md,*.mdown,*.markdown# Kopfrechnen
## Aufgabe 1
<!--aufg 1
1. \[ 5+8\cdot 12 = \]
/aufg-->
<!--aufg 2
1.
/aufg-->
<!--ml-->
### Variante 1
1. \[ 5+8\cdot 12 = 101 \]
### Variante 2
<!--/ml-->
Weitere Aufgaben ...
Für TeX wird die Python-Konfiguration oben angepasst, so dass ˋ%ˋ als Kommentarzeichen interpretiert wird:
[settings]
task open = %\begin{aufg}
task close = %\end{aufg}
task comment prefix = %
solution open = %\begin{ml}
solution close = %\end{ml}
include = *.texEine andere Herangehensweise wäre es, im Kopf der TeX-Datei Umgebungen zu definieren, die den Inhalt beim Satz der Basisversion verstecken. Dieses Vorgehen kann z.B. für den Satz von Klassenarbeiten mit mehreren Varianten hilfreich sein.
[settings]
task open = \begin{jmlaufgabe}
task close = \end{jmlaufgabe}
solution open = \begin{jml}
solution close = \end{jml}
include = *.textask comment prefix und solution comment prefix können auch in einem
erweiterten Modus genutzt werden. Wenn die Optionen auf einen Wert im Format:
/regex/replace/
gesetzt wird, wird regex als regulärer Ausdruck benutzt und die erste
Fundstelle durch replace ersetzt. Dabei lassen sich auch Gruppen aus
regex in replace mit \1, \2, usw. referenzieren.
Ein Slash / muss durch \/ maskiert werden, wenn er in regex oder
replace vorkommen soll.
Dieser Modus kann hilfreich sein, um komplexere Kommentar-Syntax oder ganz andere Einsatzzwecke zu ermöglichen.
Diese .jml Datei würde die Aufgaben-Markierungen auf ein HTML-Format
ändern und innerhalb des Aufgaben-Blocks in jeder Zeile die Kommentare
entfernen, die ein TODO: enthalten.
[settings]
task open = <!--aufg start-->
task close = <!--aufg end-->
task comment prefix = /<!-- TODO: (.+) -->/\\1/Zum Beispiel würde aus
<!--aufg start-->
<!-- Füge hier deine Lösung ein -->
<!-- TODO: <div></div> -->
<!--aufg end-->dann die Ausgabe
<!-- Füge hier deine Lösung ein -->
<div></div>Wie man sieht, bleibt der Kommentar ohne TODO: erhalten.
In Entwicklungsumgebungen wie Eclipse, IntelliJ und vscode lässt
sich jml relativ einfach als externes Tool einbinden. Die IDEs erlauben
in der Regel die Verwendung von Platzhaltervariablen, mit denen der Aufruf
von jml angepasst werden kann.