File handling: Allow blanks and ümläüts in project path

[cagix]

Gemäß Issue #1325 dürfen aktuell keine Leer- oder Sonderzeichen im Dateipfad des Projekts oder des Starter-JARs sein, da sonst das Einlesen von Dateien im Dungeon nicht funktioniert.

• TODO: Zählt eine Tilde (~) auch zu den bisher nicht erlaubten Zeichen? Würde das auch im Ansatz in Dungeon Starter + JUnit: Allow spaces or special characters in paths #1366 mit erledigt?

Im Zuge des PR #1344 wurde ein erster Versuch zum Fixen des Problems unternommen. Es hat sich aber schnell gezeigt, dass das Problem wesentlich tiefer geht und es hier eine Analyse und nachfolgend ein Konzept sowie eine Dokumentation braucht.

Es wird an verschiedenen Stellen aus Dateien gelesen, und es muss sowohl für den Start vom lokalen Filesystem als auch für den Start aus einem JAR heraus funktionieren. Zusätzlich werden in der DSL an einigen Stellen Dinge aus JAR-Files eingelesen, unabhängig davon, von wo der Dungeon gestartet wurde.

Es braucht eine Analyse, wo überall Dateien eingelesen werden und was dort jeweils genau passiert bzw. benötigt wird. Es braucht ein Konzept, wie man das möglichst mit einer zentralen Hilfsklasse o.ä. lösen kann, so dass nicht an jeder Stelle immer wieder das Rad neu erfunden wird. Zusätzlich sollte der Zugriff für die nutzenden Klassen uniform sein, d.h. diese sollten sich keine Gedanken machen müssen, von wo nun genau gestartet wurde ...

Die Analyseergebnisse, Lösungsansätze sowie diskutierten Vor- und Nachteile der Ansätze und die Entscheidung für die Umsetzung müssen vernünftig in der Dokumentation zusammengefasst werden.

Eine in #1344 (comment) diskutierte Skizze findet sich in als Experimentierbaukasten in https://github.com/Programmiermethoden/temp_path_in_jar_or_local. Im Prinzip könnte es grundsätzlich so aussehen:

        String folder = "wuppie";
        URI uri = Main.class.getResource(folder).toURI();

        Path myPath;
        if (uri.getScheme().equals("jar")) {
            // inside JAR
            FileSystem fileSystem = FileSystems.newFileSystem(uri, Collections.<String, Object>emptyMap());
            myPath = fileSystem.getPath(folder);
        } else {
            // normal filesystem, e.g. in IDE
            myPath = Paths.get(uri);
        }

        Files.walk(myPath, 2).forEach(System.out::println);

Auswirkungen müssen aber analysiert werden - beispielsweise muss hier das FileSystem bis zur endgültigen Verarbeitung offen bleiben. Ein Idee könnten hier Methodenreferenzen sein, die in der Hilfsklasse zur Verarbeitung der gefundenen Ordner/Dateien ausgeführt werden.

Allgemein wird der Zugriff auf Ressoucen via Path oder File nicht empfohlen, man soll bei Ressourcen sicherheitshalber über die Stream-API gehen: InputStream wuppie = this.getClass().getResourceAsStream("/wuppie.txt"); (vgl. https://docs.oracle.com/javase/8/docs/technotes/guides/lang/resources.html, https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html, https://stackoverflow.com/questions/25362943/cant-load-resources-file-from-jar, https://stackoverflow.com/questions/20389255/reading-a-resource-file-from-within-jar, https://stackoverflow.com/questions/64411243/use-src-test-resources-as-directory-with-gradle-java). Der Stream ist null, wenn die Ressource nicht gefunden wurde.

---

• TODO: Nach dem Schließen dieses Tickets auch das temporäre Repo https://github.com/Dungeon-CampusMinden/temp_path_in_jar_or_local löschen!