enhancement
major
minor
major
minor
major
#29895
deploy/local applies only to the module in the working directory: a module of a multi-module build cannot be started from the reactor root
Found in an application (E-Home, 8.0.0-alpha10) after splitting it into a reactor (root aggregator POM, app module ehome/, optional fragment module ehome-virtual/). The app's deploy/local (H2 configuration for local runs) is applied only when exec:java runs with the module's directory as working directory; started from the reactor root (./mvnw -pl ehome exec:java), the deploy aspect is not found. Workaround: the app is started from ehome/, and its POM sets h2_name and tl_storage_path to the root tmp/ so the database location stays where it was; these POM properties then override the environment variables of the same names.
Wanted: the deploy aspects resolved relative to the module (e.g. ${project.basedir}), or a documented property naming the deploy directory, so a reactor module can be started from the root.
Analyse
Der Resourcen-Pfad einer im Entwicklungsmodus gestarteten Anwendung wird von PathInfo (com.top_logic.basic.core) aus dem Classpath aufgebaut. Der Deploy-Aspekt local wird dabei nur für das "Top-Level-Projekt" aufgenommen, und als Top-Level-Projekt gilt das Classpath-Projekt, dessen Verzeichnis dem Arbeitsverzeichnis der JVM (new File(".")) entspricht. Alle anderen Aspekte (z.B. private) werden für jedes Classpath-Projekt aufgenommen.
Beim Start aus dem Reactor-Root ist das Arbeitsverzeichnis das Aggregator-Verzeichnis, in dem kein Classpath-Projekt liegt: Kein Projekt gilt als Top-Level, deploy/local des Anwendungsmoduls wird verworfen, und die darin per metaConf.txt eingebundene Datenbankkonfiguration (db-h2.xml) fehlt. Die Anwendung startet dann mit ConfigurationException: No database configured.
exec:java läuft in der Maven-JVM und kennt kein Arbeitsverzeichnis (der Parameter workingDirectory gilt nur für das forkende exec:exec); ab JDK 11 ignoriert die File-API außerdem Änderungen an user.dir. Das Arbeitsverzeichnis ist damit als Kriterium ungeeignet.
Reproduzierbar in der Engine selbst mit mvn -pl com.top_logic.demo.react exec:java aus dem Reactor-Root.
Lösung
PathInfo bestimmt das Top-Level-Projekt aus dem Abhängigkeitsgraphen des Classpaths statt aus dem Arbeitsverzeichnis: Top-Level ist das produktive Classpath-Projekt (target/classes mit pom.xml), von dem kein anderes Classpath-Projekt abhängt (die Senke des Graphen, den DependencyResolver ohnehin aufbaut). Bleiben mehrere Kandidaten (z.B. ein Testprojekt neben dem Anwendungsprojekt), entscheidet wie bisher das Arbeitsverzeichnis. Der Aspekt local wird für dieses Projekt aufgenommen.
Damit startet ein Reactor-Modul auch aus dem Root (mvn -pl <modul> exec:java); die Datenablage (tmp/app-data, tmp/scratch) liegt dann relativ zum Startverzeichnis, also im Root, wo sie bei einem Reactor gewünscht ist. Der im Ticket beschriebene Workaround (Start aus dem Modul, h2_name/`tl_storage_path` im POM) entfällt. Es gibt keine neue Property und keine Änderung an tl-parent-app.