build.jenesis.repository.format.testkit

build.jenesis

build.jenesis:build.jenesis.repository.format.testkit is a Maven Central artifact (jar) for the JVM. It has 2 published versions. Browse versions below for dependency snippets and security details.

Recommended: 0.7.0 2 versions jarChecking...

Add to your project0.7.0

<dependency>
    <groupId>build.jenesis</groupId>
    <artifactId>build.jenesis.repository.format.testkit</artifactId>
    <version>0.7.0</version>
</dependency>

Version Details — 0.7.0

Packaging
jar
Direct Deps
0
Total Deps
0
Published
Unknown
License
Apache-2.0

<p>{@code FormatContract} states each documented clause once - publish serves the exact bytes, a {@code HEAD} is answered from metadata without opening the blob, the shared traversal probe vectors are refused at both the request seam and the coordinate seam, a withheld version leaves every enumeration surface, a proxy leg holds an upstream body to the digest its protocol advertises and streams it, and a generated index is stable enough to revalidate - and {@code FormatFixture} is how one format supplies the realistic corpus those checks run over. A format is covered by writing a fixture, never by copying assertions into another hand-written per-format suite, which is how the four free layouts drifted apart before this kit existed. <p>The supporting doubles are part of the contract rather than conveniences: {@code WitnessStore} is the store decorator that <em>throws</em> when a blob is opened (so HEAD-from-metadata is proven, not asserted) and that trips on an artifact-sized buffered write or on a body the format materialised before handing it to the store (so streaming is proven over a {@code GeneratedBody} that never exists as an array); {@code ContractExchange} is the in-memory {@code FormatExchange} that also records which response overload a format used and revalidates a buffered one the way the servlet dispatcher does; {@code TraversalVectors} holds the probe vectors as plain data so every format is probed with the same list rather than each fixture inventing its own. <p>The module depends only on the format SPI (and through it the store SPI) - no junit, no assertion library, no server - so the downstream distribution's test modules can require it for their own fixtures exactly as they already require the store testkit. The classes are test doubles; nothing here provides a service, so the module is inert on a runtime graph.

Checking security advisories...