[DSL] `@DSLType` automatisch einlesen

[malt-r]

Wie hier https://github.com/Programmiermethoden/Dungeon/pull/687#issuecomment-1561976953 dargestellt, stellt es eine Fehlerquelle dar, dass die per @DSLType markierten Datentypen nochmals händisch in das GameEnvironment eingebunden werden müssen. Daher sollte das Einlesen dieser Datentypen automatisiert werden.

Dafür müsste das gesamte Java-Projekt nach Klassen, die mit @DSLType markiert sind durchsucht werden und für diese Klassen muss an dieser Stelle typeBuilder.createTypeFromClass aufgerufen werden.

@AMatutat das SHK-Label kommt daher, dass es hier prinzipiell nicht um funktionale Entwicklung der DSL geht, sondern um eine Hilfsfunktion

[JudiTeller]

Ich hab mal eine erste Iteration hierfür im jetzt gelinkten Branch geschrieben. Leider weiß ich nicht, wie ich das genau testen könnte, ob die Klassen korrekt geladen werden :sweat_smile:

[JudiTeller]

Aktuell gibts noch Probleme mit den relativen Pfaden zu contrib und core unter game/src und ich baue gerade noch Methoden mit ein, dass ich aus der File den fully qualified name der Klasse rausziehen kann.

[JudiTeller]

Ok die Probleme sind soweit gefixt aktuell werden die 6 Klassen gefunden, die vorher hardcoded waren (QuestConfig.class, Entity.classPosition Component.class VelocityComponent.class AIComponent.class CollideComponent.class) plus zusätzlich die HealthComponent.class

der Aufbau ist gerade noch etwas unschön, vorallem das mehrfache Einlesen des Codes der jeweiligen Files, aber für ein Konzept sieht es so aus, als ob es funktioniert :D

[malt-r]

Das sieht schon ziemlich gut aus :+1: Eine Frage, die ich mir aktuell stelle, ist, ob das auch im ausgelieferten Programm funktioniert und wie sich das da mit den Dateipfaden verhält (sind die Dateien auch in dem .jar enthalten?). Um das abzuschätzen, stecke ich aber ehrlichweise nicht tief genug in der Java-Welt drin. Und einen Änderungswunsch hätte ich, nämlich, dass die Methode loadClasses nach unterschiedlichen Annotationen filtern kann (also bspw. auch DSLTypeAdapter).

[JudiTeller]

Guter Einwand. Bin auf jeden Fall darauf gestoßen, dass wenn das Programm zu .jar compiled wird, relative Pfade im Code dann parallel zur Location der .jar File aufbauen. Habe aber auch ad-hoc keine Ahnung, wie man das dann speziell für den Gebrauch mit ner .jar umschreibt, da muss ich noch weiter recherchieren.

Methodensignatur habe ich umgeschrieben, dass man jetzt bei Aufruf die Annotation.class mitgibt.

[malt-r]

@JudiTeller wie ist hier der Stand?

[JudiTeller]

Mit dem aktuellen Stand können auf jeden Fall schon nach beliebigen Annotations gesucht werden. Es wird fest in core und contrib nach den Klassen gesucht.

Es wird aber aktuell nur funktionieren, wenn direkt per gradle gestartet wird.

In #818 werden wir noch allgemein einen Fileread einbauen, der automatisch zwischen .jar compiled / nicht compiled unterscheiden werden kann. Darauf können wir hier dann noch erweitern.

[AMatutat]

Auf #818 warten, dann sollte das gehen

[AMatutat]

ich pack hier mal das later dran, wegen der Abhängigkeit mit #818

[malt-r]

Das hier gehört nicht wirklich in den Taskbuilder-Milestone, eher zu einem "General/Convenience"-Milestone, den es (noch) nicht gibt.