Working with the modular-tiles example I wanted to add an option (via menu) to add/remove plugins. This requires copying files to the watched plugins directory, and removing files from said directory.
The problem is, the application has no clue where this directory is located! The application can be launched from any directory within the file system, yet the plugins directory is set relative to the basedir of the given layers config file. For this use case I could get away by having access to the value of the computed basedir (calculated by org.moditect.layrry.launcher.LayrryLauncher). This value could be exposed as a System property and would have to blindly assume that the plugins directory remains as plugins.
A better approach would be to let the running application have access to parsed the Layers configuration or even the Layers instance. If the later then it should not be possible for the app to run the Layers once again.
Working with the
modular-tilesexample I wanted to add an option (via menu) to add/remove plugins. This requires copying files to the watched plugins directory, and removing files from said directory.The problem is, the application has no clue where this directory is located! The application can be launched from any directory within the file system, yet the
pluginsdirectory is set relative to thebasedirof the given layers config file. For this use case I could get away by having access to the value of the computedbasedir(calculated byorg.moditect.layrry.launcher.LayrryLauncher). This value could be exposed as aSystemproperty and would have to blindly assume that the plugins directory remains asplugins.A better approach would be to let the running application have access to parsed the
Layersconfiguration or even theLayersinstance. If the later then it should not be possible for the app to run the Layers once again.