If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/geoserver/geoserver shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit today
• 18 active contributors
• Distributed ownership (top contributor 19% of recent commits)
• Other licensed
• CI configured
• Tests present
• ⚠ Non-standard license (Other) — review terms

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live geoserver/geoserver repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/geoserver/geoserver.

What it runs against: a local clone of geoserver/geoserver — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in geoserver/geoserver | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of geoserver/geoserver. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/geoserver/geoserver.git
#   cd geoserver
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of geoserver/geoserver and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "geoserver/geoserver(\\.git)?\\b" \\
  && ok "origin remote is geoserver/geoserver" \\
  || miss "origin remote is not geoserver/geoserver (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "pom.xml" \\
  && ok "pom.xml" \\
  || miss "missing critical file: pom.xml"
test -f ".github/workflows/linux.yml" \\
  && ok ".github/workflows/linux.yml" \\
  || miss "missing critical file: .github/workflows/linux.yml"
test -f "CONTRIBUTING.md" \\
  && ok "CONTRIBUTING.md" \\
  || miss "missing critical file: CONTRIBUTING.md"
test -f "CODE_OF_CONDUCT.md" \\
  && ok "CODE_OF_CONDUCT.md" \\
  || miss "missing critical file: CODE_OF_CONDUCT.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/geoserver/geoserver"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

GeoServer is an open-source Java server that publishes and serves geospatial data using OGC standards (WFS, WCS, WMS, OGC API Features). It acts as the reference implementation for Web Feature Service and Web Coverage Service, enabling users to share, edit, and access spatial data in multiple formats (GeoPackage, GeoTIFF, Shapefile, GML) through standardized web protocols. Monolithic Maven multi-module architecture: core engine under src/ with hundreds of submodules organized by capability (coverage, feature service, security, rest, web-ui), separate build tools in build/ (assembly_test/ for plugin validation, acceptance/ for Docker-based integration tests), documentation in doc/ as Markdown with MkDocs, and GitHub Actions workflows orchestrating builds and testing across src modules.

GIS administrators, geospatial data engineers, and organizations managing spatial data infrastructure who need to expose geospatial datasets via standardized web services; also contributors to the OGC standards community testing compliance implementations.

Highly mature and production-ready: GeoServer is an established reference implementation with extensive CI/CD workflows (.github/workflows/ contains 15+ test suites including acceptance, CITE compliance, PostGIS integration), comprehensive multi-platform testing (Linux, Windows, macOS), and active community-driven development visible through organized issue tracking via JIRA and structured release processes (build/release.sh).

Low technical risk for core functionality; primary risks are maintenance velocity (monolithic 47M+ LOC Java codebase makes contribution onboarding steep) and dependency management complexity across 2000+ Maven modules. Minimal risk of abandonment given OGC reference implementation status and active CI (no stale workflow files), though large codebase means individual contributor impact is diluted.

Active development across OGC standard compliance, extension ecosystem, and infrastructure: 15 parallel GitHub Actions workflows handling acceptance testing, CITE compliance validation, platform-specific builds (Linux locales/timezone variants, macOS, Windows), javadoc generation, and dependency management via Dependabot. Recent work visible in backport automation (.github/workflows/backport.yml) and structured acceptance testing (build/acceptance/ with Docker Compose and geodatabase setup).

Clone and build via Maven: git clone https://github.com/geoserver/geoserver.git && cd geoserver/src && mvn clean install. For documentation development: python3 -m venv venv && source venv/bin/activate && pip install -r requirements.txt && mkdocs serve --livereload from the doc root.

Daily commands: From src/: mvn clean install builds all modules. Run embedded GeoServer via Maven plugin (typically mvn jetty:run in web module, though exact command in specific submodule POM). Acceptance tests: cd build/acceptance && docker-compose -f compose.yml up (requires Docker, geodatabase init via build/acceptance/geodatabase/001_create_schemas.sql).

• README.md — Entry point documenting GeoServer's purpose as an OGC standards-compliant geospatial data server; essential for understanding project scope and mission.
• pom.xml — Root Maven configuration defining the multi-module build structure, dependencies, and plugin ecosystem for the entire GeoServer project.
• .github/workflows/linux.yml — Primary CI/CD pipeline for automated testing on Linux; critical for understanding how contributions are validated before merge.
• CONTRIBUTING.md — Developer guidelines covering contribution workflow, code standards, and pull request expectations specific to this project.
• CODE_OF_CONDUCT.md — Community standards and conduct expectations for all contributors and community members.
• build/assembly_test/src/test/java/org/geoserver/AssemblyTest.java — Core assembly test validating the packaged distribution; critical for understanding how the final deliverable is validated.
• .github/dependabot.yml — Automated dependency update configuration managing security patches and library upgrades across the codebase.

• Maven Build System (Maven 3.x, pom.xml, Java 11+) — Dependency resolution, compilation, test execution, artifact packaging across all modules
  • Failure mode: Build failures propagate to CI; PR blocked until resolved
• GitHub Actions CI Pipeline (GitHub Actions YAML, workflow matrix, runners) — Multi-platform testing (Linux/Windows/macOS), CITE compliance validation, Docker image builds, artifact caching
  • Failure mode: PR blocked by failed checks; requires re-push to retry workflows
• Assembly — undefined

Add a New OGC Web Service Implementation

1. Create a new service module in the multi-module Maven structure (pom.xml)
2. Implement the OGC service interface following WFS/WCS/WMS patterns (build/assembly_test/src/test/java/org/geoserver/DefaultPluginTester.java)
3. Register the service in the plugin registry for discovery (build/assembly_test/src/test/java/org/geoserver/PluginRegistry.java)
4. Add CITE compliance tests matching the service standard (build/cite/compose.yml)

Add a New Data Store Provider

1. Create a new module for the data store implementation (pom.xml)
2. Add sample test data matching the new store type (build/cite/gpkg12/citegpkg-1.2/coverages)
3. Register in plugin architecture for dynamic loading (build/assembly_test/src/test/java/org/geoserver/PluginRegistry.java)
4. Include acceptance tests in Docker-based test suite (build/acceptance/compose.yml)

Add Platform-Specific Testing

1. Create new workflow file in .github/workflows/ following existing patterns (.github/workflows/linux.yml)
2. Define test matrix, caching strategy, and artifact uploads (.github/workflows/windows.yml)
3. Reference assembly tests to validate distribution (build/assembly_test/src/test/java/org/geoserver/AssemblyTest.java)

Add a New Docker-Based Integration Test

1. Create a new Dockerfile for test environment (build/cite/geoserver/Dockerfile)
2. Define Docker Compose service configuration (build/cite/compose.yml)
3. Add test data and fixtures as subdirectories (build/cite/gpkg12/citegpkg-1.2/coverages)
4. Create corresponding GitHub Actions workflow (.github/workflows/cite.yml)

• Java / Maven — OGC standard implementations require JVM ecosystem; Maven enables modular multi-project builds with dependency management for geospatial libraries (GeoTools, JTS)
• GitHub Actions Workflows — Native CI/CD with matrix testing across Linux/Windows/macOS; integrates directly with PR validation and release automation
• Docker & Docker Compose — Isolates test environments (PostGIS, geodatabases, GeoServer) ensuring reproducible CITE compliance and acceptance testing across platforms
• OGC CITE Test Suites — Mandatory compliance validation for WFS, WCS, WMS standards; ensures interoperability with OGC-compliant clients

• Multi-module Maven structure with separate plugin registry

  • Why: Enables modular extensibility and dynamic plugin discovery without tight coupling
  • Consequence: Increased build complexity; requires understanding of Maven reactor and plugin classpath isolation

• Separate Docker Compose configurations for CITE vs. acceptance testing

  • Why: Isolates OGC standards compliance from real-world acceptance scenarios; allows independent test data and environment tuning
  • Consequence: Maintenance overhead; duplicate infrastructure-as-code that must stay in sync

• Parallel CI workflows (Linux/Windows/CITE/macOS) with matrix testing

  • Why: Catches platform-specific bugs early; validates geospatial library behavior across OS platforms
  • Consequence: Slower PR feedback due to runner queue; higher GitHub Actions minutes consumption

• Not a real-time streaming service (designed for request/response OGC Web Services)
• Not a database system (relies on external PostGIS, FileGDB, ArcSDE connectors)
• Does not handle binary GIS raster processing (delegates to ImageMosaic and GeoTools coverage readers)
• Not a client-side rendering engine (publishes data; clients render via WMS/WFS responses)

Maven multi-module build requires building from src/ (not root)—running mvn clean install from root directory will fail. CITE compliance tests require specific OGC test suites not in repo; .github/workflows/cite.yml downloads them dynamically. Docker acceptance tests need significant disk space and Docker daemon running; geodatabase initialization script (.github/workflows/postgis_appschema_online.yml) expects PostGIS availability. JVM memory: .mvn/jvm.config sets defaults for large codebase—override if builds OOM. Modules have complex interdependencies; changes to core (e.g., security filters) can break dozens of submodules silently if tests don't catch them.

• Web Feature Service (WFS) — GeoServer is the OGC reference implementation; understanding WFS request/response semantics (GetFeature, DescribeFeatureType) is essential for feature service module changes
• Web Coverage Service (WCS) — Parallel OGC standard for raster data; GeoServer's coverage modules implement WCS GetCoverage, DescribeCoverage—needed for raster publication work
• GeoTools Filter Encoding — OGC standard query language used throughout GeoServer for property filtering in WFS/WMS; custom filters in REST API depend on proper Filter AST parsing
• Spring Security ACLs — GeoServer uses Spring Security with custom ACL implementation (src/security/) for layer/resource-level access control; authentication/authorization changes require understanding Spring's principal/authority model
• Maven Multi-Module Builds — GeoServer's 2000+ modules use complex dependency graphs and profiles (see src/pom.xml); broken module builds can hide failures—understanding Maven reactor behavior is critical
• OGC API Features (formerly WFS 3.0) — Modern REST-based alternative to WFS SOAP/XML; GeoServer implements both—new API work happens in dedicated modules with JSON/GeoJSON focus
• Docker Compose for Integration Testing — build/acceptance/ uses Compose for multi-container test environments (GeoServer + PostGIS + test harness); understanding orchestration is needed to debug acceptance test failures locally

• geotools/geotools — Core geospatial processing library that GeoServer depends on; handles vector/raster processing, coordinate transforms, and data access
• opengeospatial/geoapi — OGC GeoAPI interfaces that GeoServer implements; defines standards for Feature, Geometry, and CRS APIs used throughout codebase
• boundlessgeo/suite — Commercial derivative/companion of GeoServer providing extended features and enterprise support for same spatial data publication use case
• CartoDB/PostGIS — Spatial database backend frequently used with GeoServer for feature service data storage; integration tested in .github/workflows/postgis_appschema_online.yml
• OSGeo/GDAL — Geospatial data translation library; GeoServer wraps/invokes GDAL via ogr extension for format conversion and advanced raster handling

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add GitHub Actions workflow for Python acceptance testing with GeoServer Cloud integration

The repo has a build/acceptance directory with compose.yml, requirements.txt, and a Dockerfile for acceptance testing infrastructure, but there is no corresponding GitHub Actions workflow to run these tests in CI. Currently, acceptance.yml exists but likely doesn't cover the Python-based acceptance tests. This would ensure the python-geoservercloud dependency (0.8.3) and local development path work correctly across PRs.

• [ ] Review existing .github/workflows/acceptance.yml to understand current acceptance test setup
• [ ] Create a new workflow (e.g., .github/workflows/acceptance_python.yml) that uses build/acceptance/compose.yml
• [ ] Add build/acceptance/requirements.txt installation and test execution steps
• [ ] Test with geoservercloud==0.8.3 and validate the commented-out local development path works
• [ ] Document expected environment variables and Docker requirements in the workflow

Add integration tests for OGC WFS/WCS standard compliance in build/assembly_test

GeoServer is the reference implementation of OGC WFS and WCS standards (as stated in README), but the build/assembly_test directory only contains basic assembly verification tests (AbstractPluginTester, DefaultPluginTester). Adding dedicated tests for WFS and WCS endpoint compliance would catch regressions and validate standard conformance during builds.

• [ ] Review existing test structure in build/assembly_test/src/test/java/org/geoserver/
• [ ] Create WFSStandardComplianceTester.java and WCSStandardComplianceTester.java classes extending AbstractPluginTester
• [ ] Implement tests for core WFS operations (GetCapabilities, DescribeFeatureType, GetFeature) and WCS operations (GetCapabilities, DescribeRasterDataset, GetCoverage)
• [ ] Register new testers in PluginRegistry.java
• [ ] Add documentation in build/assembly_test/README.md explaining the new compliance test coverage

Create CI workflow for locale and timezone regression testing across platforms

The repo has two specialized workflows (linux_locales.yml and linux_timezone.yml) that test locale and timezone handling, but these only run on Linux. GeoServer runs across Windows and macOS (workflows exist), but there are no corresponding locale/timezone tests for those platforms. This could catch platform-specific internationalization bugs that currently go undetected.

• [ ] Analyze linux_locales.yml and linux_timezone.yml to extract the test logic and parameterization
• [ ] Create .github/workflows/windows_locales.yml and .github/workflows/windows_timezone.yml based on windows.yml template
• [ ] Create .github/workflows/macos_locales.yml and .github/workflows/macos_timezone.yml based on macos.yml template
• [ ] Ensure consistency in locale/timezone test matrices (e.g., same locales: en_US, fr_FR, ja_JP and timezones: UTC, PST, Asia/Tokyo)
• [ ] Document the locale and timezone test strategy in CONTRIBUTING.md

• Add unit test coverage for lesser-used output format modules (e.g., src/extensions/geopackage/ or src/extensions/ogr/)—most have minimal test suites visible in standard Maven structure.
• Improve documentation in doc/ for extension development: add concrete examples for plugin/extension creation using build/assembly_test/ as reference; currently missing step-by-step plugin tutorial.
• Enhance GitHub Actions matrix testing: add explicit JDK version testing (21+) to .github/workflows/linux.yml and .github/workflows/macos.yml, matching Maven compiler settings in src/pom.xml, to catch Java version compatibility bugs early.

GeoServer codebase shows reasonable security practices with CI/CD pipelines and security documentation, but has moderate concerns around dependency management, Docker configuration security, and environment file handling. The presence of outdated Python dependencies and unreviewed Dockerfile configurations are the primary risks. Recommendations focus on automated security scanning, secret management improvements, and workflow security hardening. No critical injection vulnerabilities or hardcoded credentials were directly visible, but thorough code review of the main Java codebase (not provided) would be needed for comprehensive assessment.

• High · Outdated Dependency: geoservercloud — build/acceptance/requirements.txt. The geoservercloud Python package version 0.8.3 is specified in requirements.txt. This version may contain known vulnerabilities. No upper bound is specified, but the pinned version should be verified against security advisories. Fix: Run 'pip check' and 'safety check' to identify CVEs in geoservercloud 0.8.3. Update to the latest patched version and regularly monitor for security updates.
• Medium · Environment Configuration Files in Repository — build/cite/.env, build/cite/geoserver/geoserver.env. Environment configuration files (.env files) are present in the repository structure (build/cite/.env, geoserver.env). These may contain sensitive information or database credentials if not properly managed. Fix: Ensure .env files are in .gitignore and never committed to the repository. Use environment variable management systems or secret vaults for sensitive configuration. If already committed, rotate any exposed credentials.
• Medium · Docker Configuration Exposure — build/acceptance/geoserver/Dockerfile, build/cite/geoserver/Dockerfile. Multiple Dockerfile configurations are present for acceptance and CITE testing. These Docker images may be built with hardcoded credentials or sensitive data if not properly reviewed. Fix: Review all Dockerfiles to ensure no hardcoded credentials, API keys, or passwords are embedded. Use Docker build arguments and secrets management for sensitive data. Implement image scanning with tools like Trivy or Grype.
• Medium · Public GitHub Actions Workflows — .github/workflows/. Multiple CI/CD workflows are configured (.github/workflows/) that execute automated builds and tests. These workflows may expose secrets or execute untrusted code if not properly secured. Fix: Review all workflow files for proper secret management (use GitHub Secrets, not hardcoded values). Implement branch protection rules, require code review before merge, and audit third-party actions used in workflows.
• Medium · Dependabot Configuration May Be Insufficient — .github/dependabot.yml. While dependabot.yml exists for dependency scanning, the configuration and scope are not visible. Automated dependency updates may not cover all components or may not have adequate security policies. Fix: Ensure dependabot is configured to scan all package managers (Maven, npm, pip, Docker). Set appropriate update frequency (daily for security updates), enable auto-merge for patches, and review security alerts regularly.
• Low · Incomplete SECURITY.md File — SECURITY.md. The SECURITY.md file appears to be truncated in the provided snippet, with incomplete guidance on vulnerability reporting procedures. Fix: Complete the SECURITY.md file with clear vulnerability disclosure procedures, responsible disclosure timeline, contact information (security@geoserver.org), and instructions for safe reporting.
• Low · Multiple Database/Data Files Without Apparent Versioning — build/acceptance/geodatabase/001_create_schemas.sql, build/cite/gpkg12/citegpkg-1.2/. SQL scripts and test data files are present in the repository. While acceptable for test/acceptance environments, they should be carefully managed to prevent information disclosure. Fix: Ensure test data does not contain real user data or sensitive information. Document the purpose of test fixtures and implement data sanitization procedures if migrating from production.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.