fix: improve multi-module Gradle detection for dynamic settings.gradle.kts

[HeshamHM28]

Summary

• Parse listOf(...) patterns in settings.gradle.kts for projects that build include lists dynamically (e.g. OpenRewrite uses val allProjects = listOf(...) + include(*(allProjects + ...).toTypedArray()))
• Fix include regex to use word boundary, avoiding false matches on variable names like includedProjects
• Break module voting ties using codeflash.toml module-root config so the function's own module is preferred over cross-module tests
• Add _read_config_module_root helper to read module-root from codeflash.toml/pyproject.toml
• Improve _infer_module_from_config and multi-module detection for sub-module project roots

Problem

When running codeflash --file rewrite-core/src/main/java/.../StringUtils.java --function trimIndent on OpenRewrite (a 30+ module Gradle project):

1. _extract_modules_from_settings_gradle() returned empty because settings.gradle.kts uses listOf(...) + spread operator instead of direct include("module-a") syntax
2. Without module detection, Gradle ran test globally instead of :rewrite-core:test, building all 30+ modules and failing on unrelated compilation errors
3. Even after detection, module voting produced ties (1 test in each of 3 modules) and picked the wrong module

Test plan

• All 51 existing tests pass (tests/test_languages/test_java/test_java_test_paths.py)
• Verified _extract_modules_from_settings_gradle correctly finds 29 modules from OpenRewrite's dynamic settings.gradle.kts
• Verified tie-breaking selects rewrite-core when configured as module-root
• E2E: run codeflash --file ... --function trimIndent on OpenRewrite repo

🤖 Generated with Claude Code

[claude]

Claude finished @mashraf-222's task in 4s —— View job

---

PR Review Summary

Prek Checks

✅ uv run prek run --from-ref origin/main passes (ruff check + format: no issues).
3 pre-existing mypy errors in function_optimizer.py and base.py — not introduced by this PR.
All 117 tests in the changed test files pass.

---

Code Review

Bug: _read_config_module_root returns raw path, breaks tie-breaking

test_runner.py:303 — _read_config_module_root returns the raw module-root value from codeflash.toml:

return m.group(1).strip().strip("/")  # e.g. "rewrite-core/src/main/java"

The tie-breaking code at line 401 then compares this against Gradle module names:

if config_module and config_module in tied:  # "rewrite-core/src/main/java" in ["rewrite-core", ...]

Since module-root in codeflash.toml for Java projects is a full path like "rewrite-core/src/main/java" (as written by codeflash init), the comparison always fails and tie-breaking never activates. The sibling function _infer_module_from_config (line 309) correctly uses Path(value).parts[0] to extract just the module directory — _read_config_module_root should do the same. Fix this →

Design: setup_coverage on GradleStrategy is now dead code in run_behavioral_tests

test_runner.py:526-527 still calls strategy.setup_coverage(...) before run_tests_with_coverage(...) overwrites coverage_xml_path at line 539. After this PR, GradleStrategy.setup_coverage (line 1029) is just a stub that returns a predicted path without doing anything — the actual coverage setup was moved into run_tests_with_coverage. The first call is dead code: its return value is silently discarded. The comment on enable_coverage in run_tests_via_build_tool line 720 acknowledges the old parameter is kept for "interface compatibility", but the call at line 527 in run_behavioral_tests should be guarded or removed to avoid confusion. Fix this →

Low risk: _INCLUDE_PATTERN greedy over-match with DOTALL

test_runner.py:26 — The pattern include\s*\(?[^)]*\)? with re.DOTALL greedily matches from include until the first ) (or end of string) across multiple lines. For Groovy DSL includes without parens (include 'a', 'b'), [^)]* consumes everything to the next ) or end-of-file. If rootProject.name = 'project' or other quoted strings appear AFTER the include block (unusual but valid), they'd be falsely extracted as module names.

The stated fix ("use word boundary") is implemented as (?:^|(?<=\s)) which still matches include preceded by whitespace — for example in val includedProjects = listOf(...), include would match if preceded by space. This isn't a practical concern (since the subsequent characters fail the Gradle DSL test), but the fix doesn't achieve the stated word-boundary goal. Using \b before include would be more precise. That said, this is unlikely to affect real projects and the tests all pass.

---

Duplicate Detection

_read_config_module_root (test_runner.py:294) re-implements config reading with a raw regex, while code_utils/config_parser.py already has a full TOML parser for codeflash.toml. This is intentional (lightweight, no full parse needed at runtime during module detection) but worth noting. It does NOT reuse the existing path resolution logic which is the source of the bug above.

No other duplicate logic found.

---

Test Coverage

File	Coverage
gradle_strategy.py	33%
test_runner.py	57%
line_profiler.py	58%
tracer.py	82%

Low coverage on gradle_strategy.py is expected — subprocess execution paths (Gradle commands, JaCoCo conversion) cannot easily be unit tested. The critical new logic (_find_top_level_block, _ensure_maven_central_repo, _update_existing_codeflash_dependency, add_codeflash_dependency) is well covered by the 20 new unit tests.

Missing test: The tie-breaking logic in _find_multi_module_root has no test that verifies codeflash.toml module-root actually breaks a tie. The only tie test (test_tied_modules_fallback) just asserts test_module in ("clients", "streams") without a config file present.

---

Summary

The core work is solid and well-tested: Maven Central dependency management (replacing local JAR copy), JaCoCo via runtime agent, multi-line include detection, parent-module walking, and timeout bumps are all correct. Two items to address before merging:

1. Bug (functional): _read_config_module_root needs Path(value).parts[0] to extract the module name from the path — without this, the tie-breaking feature silently doesn't work.
2. Design (minor): the setup_coverage call at run_behavioral_tests:527 is dead code for Gradle and should be cleaned up to avoid confusing future readers.

[codeflash-ai]

⚡️ Codeflash found optimizations for this PR

📄 26% (0.26x) speedup for _ensure_maven_central_repo in codeflash/languages/java/gradle_strategy.py

⏱️ Runtime : 370 microseconds → 294 microseconds (best of 250 runs)

A dependent PR with the suggested changes has been created. Please review:

• ⚡️ Speed up function _ensure_maven_central_repo by 26% in PR #2015 (fix/gradle-maven-central-dependency) #2016

If you approve, it will be merged into this PR (branch fix/gradle-maven-central-dependency).

[codeflash-ai]

⚡️ Codeflash found optimizations for this PR

📄 23% (0.23x) speedup for _extract_modules_from_settings_gradle in codeflash/languages/java/test_runner.py

⏱️ Runtime : 2.35 milliseconds → 1.91 milliseconds (best of 52 runs)

A dependent PR with the suggested changes has been created. Please review:

• ⚡️ Speed up function _extract_modules_from_settings_gradle by 23% in PR #2015 (fix/gradle-maven-central-dependency) #2017

If you approve, it will be merged into this PR (branch fix/gradle-maven-central-dependency).

[mashraf-222]

Phase 1 committed: tree-sitter repositories block + version update logic

Changes

• _find_top_level_block(name) — generalized tree-sitter function that finds any top-level Gradle block, ignoring blocks nested inside buildscript, subprojects, allprojects
• _ensure_maven_central_repo() — rewritten to use tree-sitter instead of re.search(r"repositories\s*\{") which matched the wrong scope
• _update_existing_codeflash_dependency() — replaces old versions (e.g. 1.0.0) or old files() format with the current Maven Central coordinate, preserving indentation
• Wired into both add_codeflash_dependency() and add_codeflash_dependency_multimodule()

Validation

• 20 new unit tests (64 total, all passing)
• E2E on eureka: dependency management confirmed working (correct subprojects block added, Maven Central resolution verified with --refresh-dependencies). Full pipeline blocked by pre-existing Phase 3 JaCoCo issue (jacocoTestReport task not found for multi-module projects)
• JAR download from Maven Central verified: 16MB, correct Premain-Class: com.codeflash.AgentDispatcher

Remaining phases

• Phase 2: classpath hint for JAR resolution in tracer/line_profiler
• Phase 3: JaCoCo coverage via runtime JAR agent (unblocks full Gradle E2E)

[mashraf-222]

Phase 2 & 3 committed and pushed.

Phase 2 — classpath hint for JAR resolution:

• find_agent_jar(classpath=None) searches resolved classpath before ~/.m2/resources/dev fallbacks
• Threaded through build_javaagent_arg, build_agent_env, instrument_source_for_line_profiler, and line_profiler_step
• All parameters optional with None default — backward compatible

Phase 3 — JaCoCo coverage via runtime JAR agent:

• run_tests_with_coverage() now injects -javaagent:{runtime_jar}=destfile={exec} via JAVA_TOOL_OPTIONS (AgentDispatcher routes destfile= to JaCoCo PreMain)
• Tests run without jacocoTestReport task — eliminates "task not found" error on multi-module projects
• .exec → .xml conversion via shaded JaCoCo CLI: com.codeflash.shaded.org.jacoco.cli.internal.Main
• setup_coverage() simplified — no longer mutates build.gradle
• Removed _JACOCO_INIT_SCRIPT constant and enable_coverage branches from run_tests_via_build_tool
• Maven coverage is completely separate (MavenStrategy) and unaffected

Running E2E on eureka to validate.

[codeflash-ai]

This PR is now faster! 🚀 @claude[bot] accepted my optimizations from:

• ⚡️ Speed up function _extract_modules_from_settings_gradle by 23% in PR #2015 (fix/gradle-maven-central-dependency) #2017

[mashraf-222]

E2E Validation — Eureka (Multi-Module Gradle Project)

All five commits validated on eureka (eureka-core module, Version.toEnum):

Phase 1: Maven Central Dependency (0ab4800f)

• ✅ testImplementation "com.codeflash:codeflash-runtime:1.0.1" added via tree-sitter to eureka-core/build.gradle
• ✅ mavenCentral() in correct scope (not inside buildscript {})

Phase 2: Classpath Hint (32bbe578)

• ✅ :eureka-core:codeflashPrintClasspath resolves classpath successfully
• ✅ Runtime JAR found from Gradle-resolved classpath

Phase 3: JaCoCo via Runtime JAR Agent (1fa01a32)

• ✅ -javaagent:...codeflash-runtime...=destfile=test.exec injected via JAVA_TOOL_OPTIONS
• ✅ No jacocoTestReport task in Gradle command (the previous blocker)
• ✅ test.exec generated at eureka-core/build/jacoco/test.exec
• ✅ test.xml converted via shaded JaCoCo CLI (808KB)

Phase 4: Multi-line Include Fix (217544f9)

• ✅ All 10 eureka modules detected (was only detecting eureka-client before)
• ✅ Gradle command scoped to :eureka-core:test (was unscoped test before)
• ✅ Classfiles found at eureka-core/build/classes/java/{main,test}

Known Issue (Pre-Existing)

Test result parsing classifies JUnit test results as GENERATED_REGRESSION (Jest), causing "Couldn't run any tests" at the behavioral baseline stage. This is a pre-existing test classification bug unrelated to these changes.

Session Logs

/home/ubuntu/e2e-sessions/2026-04-07_15-03_gradle-phase4-multiline-fix/logs/eureka/toEnum.log

[mashraf-222]

E2E Validation — Full Pipeline Pass on Eureka

All commits validated end-to-end on eureka (eureka-core, Version.toEnum). Pipeline completed fully — 6 candidates evaluated, no timeout or crash.

Timeout Fixes (commits e658fb45, 389aa16f, 5e2ef37f)

Root cause: Gradle --no-daemon on eureka takes ~10 min for cold JVM startup + configuration + dependency resolution before tests even start. The previous 300s timeout killed the process mid-execution, producing partial results the pipeline couldn't use.

Fixes:

• Coverage timeout: 300s → 1200s (20 min headroom for cold builds)
• Pre-install now compiles testClasses instead of just classes — separates compilation from test execution so each gets its own timeout budget
• Pre-install timeout: 300s → 900s

Reference: PR #2013 iterated through 300→600→900s and found 900s sufficient only with warm caches. Our cold-start testing showed 900s was still borderline, hence 1200s.

Full Pipeline Checkpoint Results

Phase	Evidence	Status
Maven Central dep	Added codeflash-runtime dependency to build.gradle (tree-sitter)	✅
Multi-line include	Detected multi-module project. Module votes: {'eureka-core': 2}	✅
Pre-compile	:eureka-core:testClasses -x test → installed successfully	✅
Build cache reuse	:eureka-core:testClasses UP-TO-DATE	✅
JaCoCo agent	JaCoCo coverage XML generated (806KB)	✅
Behavioral baseline	return code 1, Parsed 22 results from SQLite	✅
Candidate evaluation	6 candidates tested	✅
Full pipeline	Completed without timeout	✅

Session Logs

/home/ubuntu/e2e-sessions/2026-04-07_16-13_gradle-1200s-timeout/logs/eureka/toEnum.log

[mashraf-222]

@claude review this PR

[claude]

Claude finished @mashraf-222's task in 4m 36s —— View job

---

PR Review

Tasks

• Read changed files
• Review gradle_strategy.py
• Review test_runner.py
• Review line_profiler.py / tracer.py
• Review tests
• Review minor files (base.py, function_optimizer.py, support.py)
• Compile final review

---

Summary

This PR makes three large improvements: (1) switch from local JAR file resolution to Maven Central dependency, (2) replace regex-based JaCoCo setup with a runtime JAR agent approach, and (3) improve multi-module detection for dynamic settings.gradle.kts. The E2E validation on eureka is solid evidence these changes work end-to-end. The core approach is sound, but there are several issues from the prior review that remain unaddressed, plus a few new ones.

---

Unaddressed Issues from Prior Review

Dead code at test_runner.py:526-527

setup_coverage is called but its return value is unconditionally overwritten at line 534. Confirmed: MavenStrategy.run_tests_with_coverage at maven_strategy.py:1085 calls setup_coverage internally, so this is dead code for both Gradle AND Maven. Fix this →

Stale exec-path in debug logging (test_runner.py:562)

jacoco_exec_path = target_dir / "jacoco.exec"   # wrong — old Maven path

Gradle now writes to build/jacoco/test.exec. This debug block will always log "JaCoCo exec file not found" on Gradle even after a successful coverage run. Fix this →

_read_config_module_root tie-breaking silently fails for typical module-root values

_read_config_module_root returns the raw TOML value stripped of leading/trailing slashes: e.g. "rewrite-core/src/main/java" for a typical Java source path. The tie-breaking check at test_runner.py:398 is config_module in tied, where tied contains Gradle module names like "rewrite-core". These won't match. The tie-breaking silently falls back to max() unless the user sets module-root to the exact module directory name.

Fix: extract the first path component in _read_config_module_root:

raw = m.group(1).strip().strip("/")
return Path(raw).parts[0] if Path(raw).parts else None

Fix this →

---

New Issues

_INCLUDE_PATTERN comment is misleading — no actual word boundary protection

The comment at test_runner.py:220 says "word boundary avoids matching variable names like includedProjects", but the pattern uses (?:^|(?<=\s)) (lookbehind on what precedes include), not include\b (word boundary on what follows). For val includedProjects = listOf("module-a"), the space before i satisfies (?<=\s), so includedProjects IS matched, extracting module-a via the wrong code path. Functionally this still produces correct results (the module names are extracted), but the listOf fallback won't fire since modules is non-empty. The comment creates false confidence about a protection that doesn't exist. Replace (?:^|(?<=\s))include with include\b (or keep the lookbehind and remove the misleading comment). Fix this →

add_codeflash_dependency_multimodule doesn't add Maven Central when upgrading old format

In add_codeflash_dependency (single-module), when upgrading from files() to Maven Central, the code calls _ensure_maven_central_repo after the update. The multi-module equivalent add_codeflash_dependency_multimodule does not:

# add_codeflash_dependency — correctly adds mavenCentral()
if updated is not None:
    updated = _ensure_maven_central_repo(build_file, updated)  # ✓
    build_file.write_text(updated, ...)

# add_codeflash_dependency_multimodule — missing the same call
if updated is not None:
    build_file.write_text(updated, ...)  # no _ensure_maven_central_repo call

If a multi-module project has a stale files() dependency, the upgrade to Maven Central will fail at resolve time because mavenCentral() isn't in the top-level repositories {}. Fix this →

Missing unit tests for _read_config_module_root and _infer_module_from_config

These functions are only exercised indirectly. Given that _read_config_module_root uses a raw regex for TOML parsing and _infer_module_from_config iterates a custom key format from gradle.properties, direct unit tests would catch regressions. In particular, a test where module-root = "rewrite-core/src/main/java" should verify the first-path-component extraction (after the fix above).

---

Minor Notes

• _convert_jacoco_exec_to_xml hardcodes build/classes/java/{main,test} — acknowledged Kotlin limitation, fine for MVP.
• The _listOf fallback skip issue (previous review) is acknowledged as a latent trap for mixed patterns but won't affect the confirmed OpenRewrite pattern.
• enable_coverage: bool = False # kept for interface compatibility in run_tests_via_build_tool signature (gradle_strategy.py:723) is a good self-documenting comment.
• New tests are thorough and well-structured. The test_does_not_copy_jar_to_libs test is a nice regression guard for the architectural change.

---

Verdict

The core changes are correct and well-validated. The three items that need fixes before merge are: (1) the stale exec-path debug log, (2) the _read_config_module_root path component extraction, and (3) the missing _ensure_maven_central_repo call in the multimodule upgrade path. The dead code at line 527 should also be cleaned up.

[claude]

Claude finished @mashraf-222's task in 4m 17s —— View job

---

PR Review

• Gather context and understand the request
• Read and analyze all changed files
• Post review feedback

---

This is a solid, well-motivated PR with good test coverage and thorough E2E validation. The three core changes (Maven Central instead of file-local JARs, JaCoCo via runtime agent instead of Gradle plugin, and dynamic listOf parsing) are all sound in principle. A few real bugs and design issues below.

---

Bugs

1. _INCLUDE_PATTERN word boundary doesn't work after include — test_runner.py:27

_INCLUDE_PATTERN = re.compile(r"""(?:^|(?<=\s))include\s*\(?[^)]*\)?""", re.MULTILINE | re.DOTALL)

The PR description says this fixes false matches on includedProjects, but (?:^|(?<=\s)) only guards what comes before include — it doesn't prevent matching includedProjects at the start of a line (where ^ matches). Example:

includedProjects = listOf("module-a", "module-b")

With re.MULTILINE, ^ matches at line start, so include in includedProjects is matched. Then [^)]* captures the rest up to ), and _QUOTED_PATTERN extracts module-a, module-b. This accidentally gives correct results only when the variable lists modules directly, but would break on e.g. includePaths = ["/src/main"]. The correct fix is \binclude\b:

_INCLUDE_PATTERN = re.compile(r"""\binclude\b\s*\(?[^)]*\)?""", re.MULTILINE | re.DOTALL)

Fix this →

---

2. add_codeflash_dependency_multimodule skips _ensure_maven_central_repo on update — gradle_strategy.py:266-277

When an existing files() dependency is updated to the Maven Central coordinate, the function rewrites the dependency line but never calls _ensure_maven_central_repo. The updated build file will reference com.codeflash:codeflash-runtime:... but have no mavenCentral() in its repositories block, so Gradle will fail to resolve it.

Contrast with add_codeflash_dependency (single-module, line 323-339) which correctly calls _ensure_maven_central_repo both inside the update branch and before inserting a new dependency.

# add_codeflash_dependency_multimodule — missing this after updating:
updated = _ensure_maven_central_repo(build_file, updated)

Fix this →

---

Design Issues

3. Dead setup_coverage call in run_behavioral_tests — test_runner.py:526-534

if enable_coverage:
    coverage_xml_path = strategy.setup_coverage(...)   # line 527 — result immediately overwritten

...

if enable_coverage:
    result, result_xml_path, coverage_xml_path = strategy.run_tests_with_coverage(...)  # line 534

GradleStrategy.setup_coverage is now just a thin path-return function (no side effects). Its result at line 527 is unconditionally overwritten at line 534. This is confusing dead code. For Maven, setup_coverage still mutates the build file, so the call must stay — but the reassignment pattern hides that asymmetry. Consider either: removing the line-527 call and having MavenStrategy.run_tests_with_coverage call setup_coverage internally, or adding a comment noting that only Maven uses the return value here.

---

4. listOf fallback condition is over-engineered — test_runner.py:228

if not modules or not any("/" not in m and "." not in m for m in modules):

The intent is: "fall back to listOf parsing if no usable modules were found via include()". But not any("/" not in m and "." not in m for m in modules) is equivalent to "all extracted modules contain / or ." — it's a fragile heuristic. In particular, if include(*(allProjects + listOf("rewrite-gradle")).toTypedArray()) extracts ["rewrite-gradle"] from the inline listOf, the condition is not True = False, the listOf fallback is skipped, and all 29 modules from allProjects are missed.

For OpenRewrite specifically this probably works because their inline include(...) contains no quoted strings. But the condition should be documented more explicitly, or simplified. A cleaner approach: always run both passes and deduplicate.

---

5. _update_existing_codeflash_dependency always overwrites the trailing comment — gradle_strategy.py:222-225

Any existing line with codeflash-runtime is replaced with ... // codeflash-runtime\n unconditionally, discarding whatever comment was on the original line. If someone had // codeflash-runtime (added by setup), it gets normalised to // codeflash-runtime. Minor, but worth noting.

---

Minor

6. _ensure_maven_central_repo matches commented-out code — gradle_strategy.py:241

if "mavenCentral()" in content:
    return content

This also matches // mavenCentral() in a comment, which would incorrectly skip adding the real declaration. Edge case but worth a note.

---

7. Test path objects missing .resolve() — test_build_tools.py, test_java_test_paths.py

Per testing.md: "Always call .resolve() on Path objects before passing them to functions under test." The new tests pass tmp_path / "build.gradle" etc. directly without .resolve(). This is consistent with many existing tests in the file (which also lack it), so not blocking, but new tests should follow the current convention.

---

What's well done

• Replacing JAR file-copy with Maven Central coordinates is the right architectural move — cleaner, version-tracked, avoids stale JARs.
• Tree-sitter for _find_top_level_block is the correct approach vs. regex-based block detection; the generalization from _find_top_level_dependencies_block to _find_top_level_block(name) is clean.
• JaCoCo via JAVA_TOOL_OPTIONS + shaded agent instead of jacocoTestReport task eliminates the multi-module task-not-found failure mode elegantly.
• The classpath hint threading (find_agent_jar(classpath=)) through build_javaagent_arg → instrument_source_for_line_profiler → JavaFunctionOptimizer._get_project_classpath() is clean and backward-compatible.
• Coverage timeout bump to 1200s is well-justified by the E2E evidence.
• Test coverage is thorough: 20 new unit tests for the tree-sitter/version-update logic, new path tests for sub-module detection.