Dynamically generate plugins list during build

[NyakudyaA]

• Run the script to generate plugin list when building image
• If building using a base image that doesn't have gdal java bindings you need to pass ACTIVATE_GDAL_PLUGIN=false, as a result gdal plugin will not be activated. Also note you cannot use tomcat:10.* as indicated in https://stackoverflow.com/questions/75475861/will-geoserver-run-over-tomcat-10-x

[tlvu]

Why the stable_plugins.txt and community_plugins.txt has been deleted from this PR?!

[tlvu]

Users were using those files to know the exact syntax to enable the plugins. Pointing to https://sourceforge.net/projects/geoserver/files/GeoServer/2.25.2/extensions/, users do not know that geoserver-2.25.2-wps-plugin.zip has to be enabled as wps-plugin !

[NyakudyaA]

Users were using those files to know the exact syntax to enable the plugins. Pointing to https://sourceforge.net/projects/geoserver/files/GeoServer/2.25.2/extensions/, users do not know that geoserver-2.25.2-wps-plugin.zip has to be enabled as wps-plugin !

That is a fair point, don't you think just adding that in the readme to clarify would be better than adding them back in the folder? The reasoning here is that the stable plugins do not change and only do so when a new version comes up, but the community plugins change quite frequently and having the list be generated at build time would make sure that there are all known stable/community plugins at build time

[tlvu]

having the list be generated at build time would make sure that there are all known stable/community plugins at build time

Yes absolutely restoring those 2 files and keep the refresh of the content of those 2 files at build time so the content is 100% up-to-date at runtime for a given version of GeoServer.

The README could mention those 2 files, like it was before. The content of those 2 files should not be in the README as you won't be able to easily refresh the content if they were in the README and will make the README too long.

I see those 2 files as part of the "user interface" of your image, much like all the various configuration variables. The user interface should be stable between release so when user pulling in a newer release they won't be surprised because the behavior has changed. This is what is called keeping backward compatibility which gives stability and predictability to the users.

So removing or renaming or changing default values, default behavior of configuration variables or configuration files is to be avoided. If you have to do it, you must mention it in some documentation, maybe a section called "Migration from version X to version Y" and list all the backward compatible changes between those versions. Ex: some config var do not exist anymore or has been renamed so the user using them have to adapt their own docker-compose.yml file before consuming the newer release.

[NyakudyaA]

@tlvu I have added them back in #677 and updated the documentation.

[tlvu]

@tlvu I have added them back in #677 and updated the documentation.

Sweet !!! Just to make sure, the mechanism to refresh the content of those 2 files at build-time is still intact right?

[fmigneault]

Just a thought.

When a version is released/tagged, which would trigger the build / dynamic download of the community plugins, can the resolved names be dumped in the stable_plugins.txt and community_plugins.txt, which both could be bundled in the artifacts/assets (e.g.: similar to how the compressed code is archived in https://github.com/kartoza/docker-geoserver/releases/tag/v2.22.2)?

This way, we would know for any given release, which set of plugins were packaged.
Using the https://github.com/kartoza/docker-geoserver/releases/ (which could include the same x.y.z-<build-date> format as the dockers) would also allow us to have full traceability of any build reference.

[NyakudyaA]

@fmigneault Yes, that can easily be done by either

• Run the two scripts that populate community.txt and stable.txt before packaging the zip archive
• Copy the .txt files out of the build image