nordisk/holger

holger-znippy-maven-repository — crate card

Reverse-engineered (from source — verify, don't trust the name)

• One-line pitch: znippy-archive-backed Maven repository — serves JARs/POMs from a .znippy, resolving GAV coords from typed index columns.
• Does: MavenRepoZnippy implements RepositoryBackendTrait. Backed by a concrete ZnippyArchive it resolves through the typed maven view (ZnippyArchive::as_maven): GAV[+classifier] coords come from the index columns the maven plugin extracted, so -SNAPSHOT and -sources/-javadoc classifiers resolve correctly instead of being mis-split from filenames. View built once (cached behind the archive's OnceLock), reused per request. A with_reader fallback keeps a generic path for non-archive/in-memory test readers.
• Key deps: traits, znippy-common (typed maven view), anyhow.
• Shape: lib, single lib.rs. Follows the shared znippy-backend pattern (typed-view + reader-fallback).
• Observed role in the workspace: Registered in server-lib as repository-znippy-maven; also used directly by bench-scenarios (the Java-jar workload) and agent-cli tests. Maven is one of the "working" formats per CLAUDE.md.

Fill in (one line each — only the human knows these)

• Primary consumer(s):
• Why it exists (vs the obvious alternative):
• Hard constraint (airgap / no-C-deps / no-FFI / pure-Rust / etc.):
• Release cadence & independence (rides a parent? own repo someday?):
• Status (production / prototype / experimental / stubbed):
• Must-NOT-change invariant:
• Biggest known gap or TODO:
• Anything a newcomer would get wrong about it: