Maven Simple Reports

This repository publishes a small collection of reports about Apache Maven repositories. Currently, a Dependabot PR dashboard (single-page app) and a Maven 4 adoption report (regenerated daily as static AsciiDoc).

Dependabot PR dashboard (SPA)

The primary user-facing report — open Dependabot PRs across the Apache Maven repositories with live build status — is a static single-page app under web/. It replaces the previous Python-generated dependabot-prs.html and is published to https://aschemaven.github.io/maven-simple-reports/dependabot-prs.

See web/README.adoc for architecture, rate-limit handling, and local development.

Maven 4 adoption report

A scheduled Python script (scripts/export_maven4_adoption.py) searches GitHub for projects using Maven 4 — POM model version 4.1.0, the Maven 4 wrapper, and apache-maven-4 invocations in GitHub Actions workflows.

Everything — Maven 4 scan, SPA build, AsciiDoc rendering, GitHub Pages deploy on main, Netlify previews on PRs and branches — runs through a single workflow .github/workflows/publish.yml. A context job decides per trigger which parts need rebuilding from source and where the run deploys; build-spa and scan-maven4 jobs run conditionally; publish-pages (for main) or publish-netlify (for previews) combines the freshly-built parts with the latest production artifacts for whatever was not rebuilt, renders the site, and deploys.

The rolling history snapshot lives on an orphan data branch as maven4-adoption-history.json — kept off main so daily time-series updates do not pollute the main commit log. No daily commits to main.

Apache Maven component repositories (the list in .gh-configuration.yaml) are filtered out as expected. Other Apache projects are kept on purpose: their Maven 4 adoption is itself a signal worth surfacing.

Future extensions

The following ideas from the original report SPEC remain open. Each one lists the tradeoff so we can pick it up when there’s a concrete reason to.

YAML POM support detection

Add a fourth GitHub code search for build.maven.yml / pom.yml files referencing the Maven 4 namespace. Drop-in extension of the existing search_* functions; no new architecture, just one more code-search query per run.

Per-feature drill-down

Distinguish build POM vs. consumer POM usage, and surface which Maven 4-specific features each adopter exercises — for example, extension declarations or schema migrations. Requires fetching and parsing each POM body, not just confirming the namespace — more bandwidth and per-repo CPU.

Cross-reference with Maven mailing list discussions

Link each adopter (or each adoption signal) to relevant dev@maven.apache.org or users@maven.apache.org threads via the sibling mail-mcp MCP server in the umbrella project.

Important

The MCP server only runs locally with an attached LLM, not on a GitHub-hosted runner. This rules out the current centralized, scheduled pipeline. A realistic path would be a separate on-demand report (e.g., a notebook or a developer-workstation CLI run) that consumes the latest committed public/maven4-adoption.adoc and produces an enriched, locally rendered companion.

Multi-forge expansion

The history schema already carries a by_forge.<forge> breakdown so additional forges (e.g. gitlab.com, codeberg.org) can plug in later without a migration. The pipeline architecture for non-GitHub forges — how the scan runs, how results travel back, where they live — is being worked out separately and intentionally not pinned down here.