JVM: Spring Java Format (spring-javaformat plugin, validate/checkFormat) is a formatter gate; the test JDK chosen by a Gradle toolchain property (-Pmockito.test.java) is the matrix axis

Offen
  • Stimmt etwas nicht?
#277 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
50/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
github-actions, java
Bereich
ci-cd, tooling

Rechercherichtung

The payload names no files in this repository. Start by finding where the validator checks code formatting and CI platform matrices, then the corpus expectations in corpus/projects.toml and the pinned checkouts it cites. Done when the spring-petclinic code-formatting check passes for Spring Java Format and the mockito matrix check counts 3 JDK versions (11, 17, 21) from the ci.yml matrix and the -Pjava property.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

spring-petclinic validates Spring Java Format on every build (Maven validate phase, Gradle checkFormat) → code-formatting FAIL "CI never runs Spotless, fmt-maven-plugin or google-java-format". mockito runs its tests on the JDK named by -Pmockito.test.java=${{ matrix.java }} through Gradle toolchains (11, 17, 21), reported as "2 JDK versions".

Evidence from the corpus audit

spring-projects/spring-petclinic / code-formatting
  • kind: UNSUPPORTED
  • actual: FAIL: JVM: CI never runs Spotless, fmt-maven-plugin or google-java-format; its formatting is not enforced
  • expected: PASS: Spring Java Format is validated on every build (Maven validate phase, Gradle checkFormat on check)
  • evidence: pom.xml:206-214: <groupId>io.spring.javaformat</groupId> / <artifactId>spring-javaformat-maven-plugin</artifactId> ... <goal>validate</goal> ... <phase>validate</phase>; build.gradle:8: id 'io.spring.javaformat' version '0.0.47'; .github/workflows/maven-build.yml:29: run: ./mvnw -B verify; gradle-build.yml:31: run: ./gradlew build
  • repro: the pom.xml plugin block above + run: mvn verify
  • confidence: high (spring-javaformat is the standard formatter of every Spring project)
mockito/mockito / platform-matrix (test JDK chosen by a Gradle toolchain property)
  • kind: UNSUPPORTED
  • actual: FAIL: CI covers 1 OS(es) (linux), 2 JDK version(s) (17, 21), 2 combination(s); expected ... at least 3 OS/JDK version combinations (found 2); every java (11|17|21, ...) job listed as linux / 17
  • expected: 3 JDK versions (11, 17, 21): the tests run on the JDK named by -Pmockito.test.java=${{ matrix.java }} through Gradle toolchains; the FAIL itself stays (one OS), but the version count and the per-job lines are wrong
  • evidence: .github/workflows/ci.yml:31: java: [11, 17, 21]; ci.yml:49-52: uses: actions/setup-java@v6 ... java-version: 17; ci.yml:75-78: ./gradlew / -Pmockito.test.java=${{ matrix.java }} / build. Same idiom: okhttp build.yml:115 -Ptest.java.version=${{ matrix.java-version }}, guava ci.yml:56 -Dsurefire.toolchain.version=${{ matrix.java }}
  • repro: the three lines above in one job
  • confidence: medium (needs project-specific build logic; worth at least recognising -Dsurefire.toolchain.version and -P*java*=<n> as a JDK version source)

Found by the regression-corpus audit (235 real repositories, one or more per ecosystem profile; corpus and expected results in corpus/). Evidence is quoted from the audited checkouts at the commits pinned in corpus/projects.toml; <checkouts>/<owner>__<repo> is such a checkout.

🤖 Generated with Claude Code

https://claude.ai/code/session_01ByTXNqDWdM7HzezrFtEvQt

Vorherrschende Sprache
Python
Sterne
4
Forks
1
Ø Merge
10 Std. 41 Min.
Gemergte PRs (30 T.)
79

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus cpp-best-practices/project_validator

Alle Issues in cpp-best-practices/project_validator

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.