Implement the All Contributors initiative in the documentation to recognize
contributions of all kinds - not just code. This includes business development,
project management, financial support, user testing, and more.
- Add .all-contributorsrc configuration file at project root
- Create new Community section in documentation
- docs/src/community/index.md - Community landing page
- docs/src/community/contributors.md - All Contributors page
- Update docs/mkdocs.yml navigation to include Community section
- Configure htmlproofer to ignore contributors page (has dynamic anchor links)
- Add initial contributors with their contribution types
How to add contributors:
Install the CLI (one-time setup):
```
npm install --save-dev all-contributors-cli
npx all-contributors-cli add <github-username> <contribution-types>
npx all-contributors-cli add username code,doc,test,bug
```
Add config server property overrides for pgconfig database connection
This change addresses the bootstrap timing issue where GeoServer services
attempt to connect to the database before environment variables are processed
by the Spring Cloud Config client. By using the config server's property
override feature, database connection parameters are now provided to all
services during the bootstrap phase, ensuring they connect to the correct
database host instead of falling back to defaults.
The configuration now clearly documents the two deployment modes (config
server vs standalone) and provides guidance on when to use each approach.
Config server overrides are used for Docker Compose deployments with
centralized configuration, while the commented environment variables can
be uncommented for Kubernetes deployments using the standalone profile.
1. Create new ogcapi extension category with features module
2. Implement OgcApiFeatureAutoConfiguration with:
- Conditional activation based on wfs/webui service
- Integration with both core and features applicationContext.xml resources
Extract the GeoServer Importer functionality into a proper GeoServer Cloud
extension to better organize and manage it as a reusable component:
1. Create gs-cloud-extension-importer module with appropriate auto-configuration classes:
- ConditionalOnImporter annotation for activation control
- ImporterConfigProperties for extension configuration
- ImporterAutoConfiguration with service-specific inner configurations
2. Implement proper service-specific activation:
- ImporterCoreConfiguration for base functionality
- ImporterWebUIConfiguration for Web UI integration (activated in webui service)
- ImporterRestConfiguration for REST API integration (activated in restconfig service)
3. Remove direct dependencies from services:
- Remove WebUI direct dependency on gs-importer-web
- Remove RestConfig direct dependency on gs-importer-rest
- Services now receive Importer functionality through gs-cloud-starter-extensions
4. Add comprehensive tests for all activation scenarios:
- Verify extension is disabled by default
- Verify proper activation of different components based on service type
- Test class loading conditions and property activation
Move vector-formats and raster-formats to input-formats parent directory
Rename starter-data-formats to starter-input-formats for consistency
Update references in dependent modules
Refactors the service-specific conditional annotations to use `@ConditionalOnProperty`
instead of `@ConditionalOnBean` for more reliable activation during the Spring Boot
bootstrap phase. This property-based approach solves initialization order issues
by checking for service properties (`geoserver.service.<type>.enabled`) instead of
relying on bean presence.
Changes include:
- Change all six conditional annotations (WMS, WFS, WCS, WPS, REST, WebUI) to use
`@ConditionalOnProperty`
- Update service `bootstrap.yml` files to explicitly set service-specific enabled properties
- Add comprehensive unit tests for each conditional annotation
- Add integration tests across all service applications to verify proper conditional
bean activation
- Add `ConditionalTestAutoConfiguration` with test beans for each service type
This improves extension reliability by eliminating race conditions during
auto-configuration and provides a more predictable activation mechanism
for service-specific extensions.
Implements a build-tools module approach as used by Apache Commons,
Spring, and Hibernate projects. This provides centralized code style rules that:
- Enforce proper license headers in all Java files
- Prohibit wildcard imports for improved code readability
- Standardize naming conventions and formatting
Build process is updated to include Checkstyle validation as part of the QA process.
- Add comprehensive README for the webmvc and extensions starters
- Remove redundant starter dependencies from GeoServer app modules
- Add clearer comments about inherited dependencies
- Clarify dependency inheritance from parent pom files
- Document which starters a typical GeoServer microservice needs
- Explain that most services only need webmvc and extensions starters
- Describe what functionality each starter provides
- Note that parent POM already includes necessary starters
This documentation helps developers understand the dependency
relationships between starters and clarifies which starters
are needed for different use cases.
This improves dependency management consistency across the codebase
while maintaining the exact same functionality.
This major refactoring improves the architecture by separating extension functionality
from their Spring Boot autoconfiguration and starter modules:
- Create dedicated autoconfiguration modules for all extensions
- Move extension configuration from starters to extension modules
- Implement ConditionalOn* annotations for precise extension activation control
- Enforce that non-WebUI applications don't have dependencies on GeoServer Wicket components
- Create a unified data-formats starter combining vector and raster formats
- Add comprehensive README.md files for all extensions
The refactoring follows these architectural principles:
1. Each extension module handles its own auto-configuration
2. UI components only activate when running in WebUI context
3. Starters become lightweight importers of extension modules
4. Core functionality is cleanly separated from framework-specific concerns
This enables better testing, cleaner separation of concerns, and ensures
services only load the components they need. Non-WebUI services now automatically
avoid loading Wicket-dependent components, reducing their memory footprint.
This commit adds support for filtering GeoTools DataAccessFactory and
GridFormatFactorySpi implementations available in GeoServer Cloud, providing
fine-grained control through YAML configuration.
Key features:
- Control which vector and raster data source formats are available through configuration
- Configuration uses user-friendly display names with placeholder resolution
- Auto-configuration runs before catalog initialization
- Vector formats filtered by deregistering DataAccessFactory instances
- Raster formats filtered using a custom FilteringFactoryCreator
- Format filtering persists even when formats are reloaded via scanForPlugins()
Configuration example:
Documentation has been added to:
- src/starters/vector-formats/README.md
- src/starters/raster-formats/README.md
- docs/configuration/index.md
- **Replaced RabbitMQ data volume with `tmpfs`** to store messages in memory for improved performance.
- **Removed unnecessary `rabbitmq_data` volume**, ensuring no leftover anonymous volumes.
- **Introduced `x-variables` with `common_env`** for shared environment variables, reducing duplication across services.
- **Updated images to use `2.27.0-SNAPSHOT`** for all services.
- **Refactored `Dockerfile` configurations**:
- Set `GEOSERVER_DATA_DIR=/tmp/tmpdatadir` during boot to ensure a clean environment.
- Fixed incorrect `-Dgeosever.backend.data-directory.location=/tmp/tmpdatadir` (typo: `geosever` → `geoserver`).
- Removed redundant directory creation as `mkdir -p /tmp/tmpdatadir` is already included.
- **RabbitMQ now stores all message data in memory (`tmpfs`)**:
- If the container restarts, all messages are lost.
- This is **not suitable for production** unless persistence is handled elsewhere.
- If persistent storage is needed, revert to a volume (`rabbitmq_data:/var/lib/rabbitmq`).
- **Previous anonymous volumes for RabbitMQ will not be reused**, users should run:
```sh
docker volume prune
```
This fixes an issue where the plugin on the geoserver uses an endpoint
that was released in 2.3.0, resulting in a 404 when trying to call an
endpoint using acl.
Relevant change: https://github.com/geoserver/geoserver-acl/pull/68
`:z` tells Docker to label the volume for shared access among multiple containers.
Turns out to be important when there's for example a geopackage
in a shared data directory.
Add `-XX:MaxRAMPercentage=80 -XX:InitialRAMPercentage=30` to the
`DEFAULT_JAVA_TOOL_OPTIONS` env var in the base JRE docker image
as they're good defaults so people doesn't need to be figuring
it out themselves.
