Diskussion: Package- und Projektstruktur

[cagix]

Wir haben das Projekt in verschiedene Gradle-Subprojekte unterteilt: Game < Dungeon < DevDungeon.

Zusätzlich haben wir verschiedene Packages, die die Subprojekte nochmal auf Java-Seite klarstellen: core und contrib. Daneben gibt es aber auch noch einigen Kram in Packages, die sich nicht diesem Schema unterordnen (v.a. die alte DSL und die Graph- und Task-Sachen).

Die Idee dahinter war mal, ein Teilprojekt (also den Ordner) per git subtree einfach auslagern und als Vorgabe für die Studis nutzen zu können. Eine andere Idee war, das Projekt als Bibliothek zur Verfügung zu stellen (JAR-File).

Problem im Sommer 2024: Die Studis sollten einen eigenen Skill realisieren. Den wollten sie im Dungeon-Subprojekt einbauen (a) wg. der Verwandtschaft zu den dort bereits realisierten Skills und (b) weil der neue Skill in einer Klasse im Dungeon-Teilprojekt eingebaut werden sollte, und gleichzeitig wollten sie interessante Klassen aus Dev-Dungeon im neuen Skill nutzen. Das klappt auch in der Gesamtschau in der IDE (die schaut sich die Packages an), aber beim Kompilieren mit Gradle werden die Subprojekte schrittweise kompiliert, d.h. man sieht nur die Packages/Klassen im aktuellen Subprojekt (und darunter). Beispiel: Eine Klasse im Dungeon kann zwar etwas aus Dev-Dungeon importieren, und in IntelliJ passt das auch - aber beim Kompilieren mit Gradle geht das in die Hose, weil Dungeon einzeln kompiliert wird und die Abhängigkeit nach DevDungeon dabei nicht aufgelöst werden kann. (Im konkreten Fall klappte ein Verschieben des neuen Skills in das DevDungeon-Teilprojekt auch nicht, weil dieser in einer HeroFactory in Dungeon integriert werden sollte ...)

Wir müssen nochmal über das Projektlayout und die Packagestruktur nachdenken, und auch über den Modus der Verteilung.

Zu klären:

• Welche Use-Cases will das Projekt adressieren und warum?
• Will das Projekt eine Library sein (es darf nur aufgerufen, aber nichts modifiziert werden)?[^1]
  • Wenn ja, wie viele Libs?
  • Wie soll die Lib verbreitet werden/nutzbar sein? Soll es ein Jar sein? Soll der Quellcode genutzt werden dürfen?
• Dürfen die Nutzenden die Strukturen als Basis nehmen, d.h. ihren eigenen Code direkt in die vorhandenen Strukturen einbauen?
• Was ist mit den Show-Cases? Sind das auf der Lib basierende Applikationen oder eher ergänzende Bausteine (d.h. selbst Lib-artig)?
  • Dev-Dungeon?
  • (alte) DSL?
  • Blockly?
• Mono-Repo oder einzelne kleinere, separate Repos?
• Packages: Brauchen wir bei separaten Gradle-Projekten (und evtl. sogar separaten Repos) unterschiedliche Basis-Packages? Oder reicht die aktuell unterhalb von core und contrib liegende Struktur für alle?

Wie machen das andere Projekte? Wie macht das beispielsweise libGDX, wo es ja auch einzelne Bausteine gibt?

[^1]: @AMatutat Jaja, ich weiss um den Unterschied, finde das hier in dieser Diskussion aber marginal :)

[cagix]

Die Studis hatten sich das Projekt lokal heruntergeladen und hatten in der IDE nur den Package-View offen. Aus dieser Sicht schien alles okay, bis dann eben zum Compilieren/Starten via Gradle, wo dann die Aufteilung in Subprojekte überraschend zuschlägt.

[tgrothe]

@cagix Sind hier "alle" angesprochen? (oder nur @AMatutat?)

[cagix]

@cagix Sind hier "alle" angesprochen? (oder nur @AMatutat?)

streng genommen ist das nur eine notiz von mir und es ist niemand angesprochen (sonst gäbe es einen assignee).

[tgrothe]

ja, ok