test(e2e): a maven and gradle client, and the 22 catalog rows they cover

Suleimi Ahmedrequested to merge
sahmed/e2e-maven-rows into sahmed/e2e-caproni-authz

What this adds

A maven and a gradle client for the e2e harness, the toolchain they need, and the 22 rows of the Maven catalog they cover.

Before this branch the Maven catalog had no automated row at all: e2e/internal/client/ carried no maven or gradle client and .mise.toml pinned no build tool or JDK, so every one of its 25 automatable rows was uncovered. Catalog coverage goes 90 → 112.

  • Toolchain. maven, gradle and a JDK pinned in .mise.toml and installed by scripts/e2e/install-tools.sh, with the version echo the other clients already have.
  • e2e/internal/client/maven and e2e/internal/client/gradle. Each confines its whole on-disk state to a scratch directory — a generated settings.xml and a local repository, never ~/.m2; GRADLE_USER_HOME for gradle — and pins its binary version the way client/oras and client/crane do.
  • registry.Client.RepositoryStatistics, plus Repository.DownloadsCount, which the contract declares and the client did not decode.
  • 22 rows across setup, auth, publish, discover, consume, one file per catalog group.

Three things the clients had to work around, found by running them

Both clients were driven against real mvn 3.9.16 and gradle 9.7.1 against a stub registry before any row was written. That turned up three things that would each have broken many rows silently:

  • A <mirrorOf>external:*</mirrorOf> mirror breaks Maven's own plugin resolution — mvn deploy dies fetching maven-resources-plugin. The client configures no mirror and routes only distributionManagement at the registry.
  • Gradle's toolchain block resolves to an exact installed JDK and fails when none matches. Neither generated script declares one.
  • The Maven surface is Basic, not Bearer (internal/auth/dispatch.go, Row 5), and the password is the credential with the username ignored.

These are recorded in e2e/README.md under "The Maven clients generate their own project files" rather than in comments, per the comment caps.

One catalog cell amended

e2e.maven.setup.repository-statistics required a virtual repository to answer 404. A virtual create returns 422 (internal/managementapi/create.go, createKindMessage), so no virtual repository can exist and the clause could never have been meaningful. The cell now reads remote only, and the row is written against it.

Three rows refused, not narrowed

Each is indexed in docs/testing/e2e/limitations.md with what would lift it.

Row Why
publish.reject-oversized maven.max_artifact_size defaults to 5 GB and is ceilinged there; server.max_body_size cannot shadow it, because the upload re-wraps the unwrapped body. Lifted by lowering it in the rig values, the npm.max_tarball_size precedent.
consume.conditional-get Its redirect arm needs a delivery mode the rig cannot serve and no API can select.
lifecycle.management-delete-storage-counters Its remote leg needs a maven upstream stub. See the note below.

A catalog inconsistency this surfaced, not fixed here: that last row's Expected outcome describes remote-repository behaviour at length, while the Maven catalog's own ## Scope puts remote Maven repositories out of scope until S14/S30. One of the two is wrong, and settling it is not this MR's business.

The diff is far past 500 reviewable LOC

Stated rather than buried. 23 files, +4,356/−26.

Group +
e2e/internal/client/{maven,gradle} (incl. 754 lines of untagged unit tests) 2,221
e2e/bootstrap/maven/ rows 1,569
e2e/internal/catalog/patterns.go 202
registry.Client and its tests 144
docs (maven.md, limitations.md, e2e/README.md) 141
harness wiring 52
toolchain 27

Splitting further would not help: the clients have no consumer until the rows land, and the rows cannot be split from patterns.go and maven.md without leaving e2e-catalog check reporting disagreements at the intermediate commit. The commit sequence already gives the one useful cut — clients (2,221) from rows (1,693) — and each of the nine commits passes check-comment-caps.sh --base origin/main on its own.

Verification

  • e2e-catalog check: 0 disagreements, covered 90 → 112.
  • go build -tags=e2e ./e2e/..., go build ./..., go test ./e2e/...: all pass.
  • golangci-lint --build-tags=e2e at the pinned 2.13.2: 0 issues.
  • check-comment-caps.sh --base origin/main: OK, and per-commit.
  • markdownlint and Vale on the changed docs: 0 errors.

The rows are unverified against a live caproni rig. The clients are verified against real mvn and gradle driving a stub registry. Every assertion about Artifact Registry's own responses — statuses, error codes, maven-metadata.xml as the registry stores and serves it, the destructive-delete lifecycle, the statistics body and its two 404 arms — is unexercised. Expect a first rig run to need fixes.

New external dependency worth a decision: each mvn deploy pulls ~23 MB / 52 jars / ~13 s from Maven Central on a cold local repository. No other suite in this tree depends on Central. Recorded in limitations.md.

Merge request reports