I am migrating to the official GeoServer docker image and it appears that for URL download the information in the documentation is misleading.
For the stable extensions, the documentation points to the build server whereas the builtin default value points to the sourceforge repository: which value do we want to promote?
For the community extensions, the default value in the image is empty, making the image not working with community extensions by default: is it on purpose or is an error to fix? I can either update the documentation or fix the image if required.
TLDR: This limitation is on purpose - community modules only intended to work for nightly builds. As you note it is technically easy to fix.
Discussion: This is an interesting point, a common request, and gets into the purpose of community modules.
Releases are built at a specific point in time, with a version number. All the core GeoServer application, and the extensions are released at that time and are available for download and use in your docker image. The GeoServer PSC has reviewed the code and has permission to distribute, they are uploaded to source forge etc…
Community modules were intended as an opportunity for developers to share their work in progress for collaboration, feedback and funding (important). As such they are built every day, and are available for download as a “snapshot” from the build server and can be run from docker (a change I made last year in order to try and get more public feedback for OGCAPI-Features development). The GeoServer PSC has not yet been asked to review the work and does not have permission to distribute yet.
The trouble with mixing a GeoServer release (made on a day) and community modules (a “snapshot” made now) is that the API may of changed and the application may not start up (having both a versioned jar and a snapshot jar for the same functionality) or may have problems (calling methods that do not exist).
You can see discussion, GEOS-11555: fix installation of extensions in various configurations), about adding docker support for mixing community modules with a release GeoServer. We would need to be clear that is “at your own risk” and something that worked yesterday may not work today.
We also have community modules that offer quite important / interesting functionality that is used by lots of people - but end up failing to attract funding to be made into an extension. In this case the availability of a community module is “good enough” and there is no motivation to “finish it” with documentation and testing.
This is an open source sustainability question - and I am not sure how best to address?
As this matter has come up repeatedly I think some kind of proposal can be made for “incubating” community modules:
Obtain permission to distribute, and publish some community modules along side the GeoServer release. The developer would indicate that the work is stable enough for public review and ask to be included in the release.
Add a note to the GeoServer welcome screen; indicating community modules installed with a warning. Or mark these modules special in the status / module list.
I think these would need a real clear point of contact (the developer) since the GeoServer PSC has not yet reviewed the work, and not yet taken on any responsibility for its long term success eh?