Actually, everything under the /data/plugins folder aims to be persisted.
However, that's not necessary not even wanted since it can causes challenges when bumping plugin versions.
Updating plugin versions at Dockerfile level is not enough because volumes are not accessible from there. Even putting the new JAR files in the /data/plugins/update folder would not work as suggested here.
This is why it is preferable to split the "plugins/" repository in two. Something like:
With plugins/data being a symlink pointing to /data/plugins.
This way, plugin binaries would now be managed exclusively at build time while persisting only the plugin data folders.
Maybe we can even provide a convenience to users and document a plugins/config folder. But this needs probably a dedicated issue with dedicated thinking about it.
Actually, everything under the
/data/pluginsfolder aims to be persisted.However, that's not necessary not even wanted since it can causes challenges when bumping plugin versions.
Updating plugin versions at Dockerfile level is not enough because volumes are not accessible from there. Even putting the new JAR files in the
/data/plugins/updatefolder would not work as suggested here.This is why it is preferable to split the "plugins/" repository in two. Something like:
With
plugins/databeing a symlink pointing to/data/plugins.This way, plugin binaries would now be managed exclusively at build time while persisting only the plugin data folders.
Maybe we can even provide a convenience to users and document a
plugins/configfolder. But this needs probably a dedicated issue with dedicated thinking about it.