Surfacing freeze store size as a signal: a green build is compatible with a growing store

Open
  • Is something wrong?
#1,700 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
48/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
java
Domain
developer-experience

Research direction

Start in the freeze package (com.tngtech.archunit.library.freeze): read FreezingArchRule, the ViolationStore interface and its default implementation, plus ViolationLineMatcher, to see where stored violations are read and reported. Then check the freeze section of the user guide and the existing tests under the freeze test package for how output is currently asserted. Done means store size (and a delta since the last state) is exposed by ViolationStore and surfaced in a frozen rule's output, with tests covering the new reporting.

Written by the indexing model from the issue text.

Description

Hi — an observation about FreezingArchRule, not a bug report. It comes from a
formal result on separation criteria I deposited recently, and I'm opening it here
because the result says ArchUnit made the right granularity choice, and points at
one thing the current output cannot show.

What the freeze mechanism does right.

A rule of the form no dependency from A to B is a separation criterion evaluated
against a declaration of what is permitted. Such criteria have a general
degeneration: if the permitted set can be enlarged, every violation can be removed
by enlarging it, without touching the code, and the required enlargement is
computable from the violations themselves.

FreezingArchRule does not do that. It records individual violations, and the
default ViolationLineMatcher matches the specific violation rather than the
rule's predicate. Absorbing an instance does not permit the class — a new violation
of the same kind still fails. That is strictly weaker than enlarging the rule, and
it is why freezing is usable at all. The downward ratchet — fixed violations are
automatically removed from the store — is the second half of the same virtue.

What the result says you cannot see.

Any graded measure computed from the current violation count is structurally
unable to signal drift along a path of successive absorptions: it assigns the
maximal value to every absorbed state and cannot decrease as absorptions
accumulate. The information about drift is not in the violation count — it is in
the store.

As far as I can tell from the user guide, nothing reports the number of stored
violations or its change over time. A green build whose store grew by forty lines
and one whose store shrank by forty are indistinguishable from outside.

Concrete question.

Would you consider surfacing store size — and more usefully its delta since the
last recorded state — as part of a frozen rule's output, or as something a
ViolationStore implementation is expected to expose? It is a small signal and it
is the one carrying the information that the green/red verdict structurally cannot.

Reference, if the argument is of interest: Closure Trivialization in Typed
Separation Systems, https://doi.org/10.5281/zenodo.21908527 — §10 makes the
granularity distinction precise.

Dominant language
Java
Stars
3.9k
Forks
350
Avg merge
3d 2m
Merged PRs (30d)
13

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from TNG/ArchUnit

All issues in TNG/ArchUnit

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.