Skip to content

fix: detect <java.version> in pom.xml — Spring Boot standard was ignored#15

Open
bipinhcs11 wants to merge 1 commit into
mainfrom
fix/detect-java-version-spring-boot-property
Open

fix: detect <java.version> in pom.xml — Spring Boot standard was ignored#15
bipinhcs11 wants to merge 1 commit into
mainfrom
fix/detect-java-version-spring-boot-property

Conversation

@bipinhcs11
Copy link
Copy Markdown
Owner

What

One-line regex fix in _detect_java_version + 9 new tests.

Why

Spring Boot projects standardly declare their Java version as:

<properties>
    <java.version>17</java.version>
</properties>

_detect_java_version only matched maven.compiler.source, maven.compiler.target, maven.compiler.release (and their bare source/target/release forms). The <java.version> property — used by the Spring Boot starter POM and recommended in the Spring Boot docs — was silently ignored, causing every such repo to report java_version: "Unknown" in both the crawl index and the doctor output.

The bug was hiding in plain sight: test_doctor.py's _tiny_spring_boot_repo() fixture already wrote a pom.xml with <java.version>17</java.version> but the test never asserted the java_version was detected.

Changes

File Change
tools/skill_generator/crawler.py Add java\.version as a leading alternative in the _detect_java_version pom.xml regex (1 line)
tests/test_crawler.py Add TestDetectJavaVersion (9 tests); import _detect_java_version

What's tested

Test Covers
test_spring_boot_java_version_property The regression<java.version>17 now returns "17"
test_maven_compiler_source Existing maven.compiler.source path still works
test_maven_compiler_release Existing bare <release> path still works
test_old_java_1_8_normalized 1.8"8" via _normalize_java_version (maven path)
test_spring_boot_java_version_1_8_normalized 1.8"8" via _normalize_java_version (java.version path)
test_no_pom_returns_unknown No pom.xml"Unknown"
test_pom_with_no_version_info_returns_unknown pom.xml present but no version element → "Unknown"
test_gradle_jvm_target Gradle jvmTarget path still works
test_gradle_source_compatibility Gradle sourceCompatibility = JavaVersion.VERSION_17 path still works

Suite: 172 → 181 tests, all green.

Follow-ups noted (not in this PR)

  • _extract_properties_prefixes in crawler.py computes a top variable (line after the for sep loop) that is assigned but never read — dead code, worth a separate chore PR.
  • The test_doctor.py fixture now implicitly exercises <java.version> detection; adding an explicit assertion for stack["java_version"] == "17" would make the intent clear — could be a one-liner follow-up.

https://claude.ai/code/session_018RA51ZizjGN5R37jqqxZzi


Generated by Claude Code

Spring Boot projects conventionally declare their Java version as:

    <properties>
        <java.version>17</java.version>
    </properties>

The previous regex in _detect_java_version only matched the Maven
Compiler plugin properties (maven.compiler.source/target/release),
so every Spring Boot repo using the <java.version> convention got
"Unknown" for java_version in the crawl index and doctor report.

Fix: extend the regex with java\.version as a leading alternative.
The maven.compiler.* and bare source/target/release paths are
unchanged.

Adds TestDetectJavaVersion (9 tests) to test_crawler.py covering the
regression case, both existing Maven patterns, old-style 1.8 → 8
normalisation, no-pom and no-version-info fallbacks, and Gradle.

The test_doctor.py _tiny_spring_boot_repo() fixture already used a
pom.xml with <java.version>17</java.version> but never asserted the
value — this fix makes that fixture exercise live detection.

Other finding (not in this PR): _extract_properties_prefixes computes
a `top` variable that is never used (dead code, one line); worth a
separate chore PR.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

https://claude.ai/code/session_018RA51ZizjGN5R37jqqxZzi
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants