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

Ouverte
  • Quelque chose ne va pas ?
#277 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
50/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
github-actions, java
Domaine
ci-cd, tooling

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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

Langage dominant
Python
Étoiles
4
Forks
1
Merge moyen
10 h 41 min
PR mergées (30 j)
79

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de cpp-best-practices/project_validator

Toutes les issues de cpp-best-practices/project_validator

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.