Skip to content

Comments

feat: Add comprehensive Gradle build tool support for Java#1319

Closed
HeshamHM28 wants to merge 14 commits intoomni-javafrom
feat/java-gradle-support
Closed

feat: Add comprehensive Gradle build tool support for Java#1319
HeshamHM28 wants to merge 14 commits intoomni-javafrom
feat/java-gradle-support

Conversation

@HeshamHM28
Copy link
Contributor

Summary

Adds full Gradle support to CodeFlash Java implementation, enabling optimization of Gradle-based Java projects alongside existing Maven support.

Changes

Core Gradle Implementation (build_tools.py)

  • GradleTestResult dataclass for test execution results
  • run_gradle_tests() function with support for:
    • Running all tests or specific test classes/methods using --tests flag
    • Multi-module Gradle projects via task prefixing (e.g., :server:test)
    • JaCoCo coverage collection with XML reports
    • Gradle wrapper (gradlew) detection with fallback to system gradle
    • Environment variable passing and timeout handling
  • compile_with_gradle() for compiling main and test sources
  • _parse_gradle_test_results() for parsing JUnit XML output from Gradle test runs
  • Updated find_gradle_executable() to accept project_root parameter for wrapper detection
  • Updated detect_build_tool() to handle both Path and string inputs

Multi-Module Support (test_runner.py)

  • Extended _find_multi_module_root() to detect Gradle multi-module projects:
    • Parse settings.gradle and settings.gradle.kts files
    • Extract module names from include statements
    • Support both Groovy DSL and Kotlin DSL syntax
    • Search parent directories for multi-module roots
  • Created build tool dispatcher in _run_maven_tests() to route to Gradle or Maven
  • Implemented _run_gradle_tests_impl() for Gradle-specific test execution
  • Converted Maven test filter format to Gradle --tests format

Test Coverage

Added comprehensive test suite with 21 tests in test_gradle_support.py:

  • Test execution (all tests, specific classes, specific methods)
  • Multi-module project support
  • Compilation (main + test sources)
  • Error handling and timeout scenarios
  • JaCoCo coverage integration
  • XML result parsing

All tests passing: 21/21 ✅

Testing

Unit Tests

uv run pytest tests/test_languages/test_java/test_gradle_support.py -v

Integration Testing (Elasticsearch)

Tested on Elasticsearch repository (multi-module Gradle project):

  • Build tool detection works correctly
  • Multi-module root detection works correctly
  • Test generation works correctly

Note: There is a separate issue with project_root detection in CodeFlash CLI that affects test execution. This is not a bug in the Gradle support code itself, but rather in how CodeFlash determines the project root from command-line arguments.

Backwards Compatibility

This PR maintains full backwards compatibility:

  • Existing Maven projects continue to work unchanged
  • Build tool detection automatically selects correct tool
  • No breaking changes to APIs or interfaces

Implementation Notes

Gradle Test Filtering

Gradle uses a different test filtering syntax than Maven:

  • Maven: com.example.TestClass#testMethod
  • Gradle: --tests com.example.TestClass.testMethod

The implementation converts between these formats automatically.

Multi-Module Support

For multi-module projects, the implementation:

  1. Detects the root settings.gradle file
  2. Parses module definitions
  3. Determines which module contains the test
  4. Executes tests with module-specific tasks (:module:test)

Coverage Collection

JaCoCo integration for Gradle:

  • Uses test jacocoTestReport tasks
  • Configures XML report generation
  • Locates reports at build/reports/jacoco/test/jacocoTestReport.xml

🤖 Generated with Claude Code

Adds full Gradle support to CodeFlash Java implementation, enabling
optimization of Gradle-based Java projects alongside existing Maven support.

Changes:
- Add GradleTestResult dataclass for test execution results
- Implement run_gradle_tests() with support for:
  - Running all tests or specific test classes/methods
  - Multi-module Gradle projects
  - JaCoCo coverage collection
  - Gradle wrapper (gradlew) detection
- Implement compile_with_gradle() for compilation
- Add _parse_gradle_test_results() for JUnit XML parsing
- Update find_gradle_executable() to accept project_root parameter
- Update detect_build_tool() to handle both Path and string inputs
- Extend _find_multi_module_root() to detect Gradle multi-module projects:
  - Parse settings.gradle and settings.gradle.kts files
  - Extract module names from include statements
  - Support both Groovy and Kotlin DSL
- Create build tool dispatcher in _run_maven_tests()
- Add _run_gradle_tests_impl() for Gradle test execution
- Add comprehensive test suite with 21 tests covering:
  - Test execution (all tests, specific classes/methods)
  - Multi-module project support
  - Compilation
  - Error handling and timeouts
  - JaCoCo coverage collection

All tests passing (21/21 in test_gradle_support.py).

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
@CLAassistant
Copy link

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.


Ubuntu seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
You have signed the CLA already but the status is still pending? Let us recheck it.

Ubuntu and others added 8 commits February 3, 2026 22:53
…erage

The previous implementation required projects to have JaCoCo plugin configured
in build.gradle. Many projects (like Elasticsearch) don't have this.

This change uses the JaCoCo agent approach instead, which:
- Downloads JaCoCo agent JAR dynamically via get_jacoco_agent_jar()
- Injects coverage collection via JAVA_TOOL_OPTIONS environment variable
- Works with any Gradle project without build file changes
- Eliminates dependency on jacocoTestReport Gradle task

Changes:
- build_tools.py: Replace jacocoTestReport task with JaCoCo agent injection
- test_runner.py: Add Gradle-specific coverage path handling
- test_gradle_support.py: Update test to check for agent env vars instead of task

Fixes optimization failures on projects without JaCoCo plugin configured.

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
…for multi-module Gradle/Maven

Multi-module projects like Elasticsearch have modules (e.g., `:server`, `:client:rest`)
with their own src/test/java directories. Previously, CodeFlash placed all tests in the
project root's `test/` directory, causing Gradle to search for tests in all modules
and fail with "No tests found" errors.

Changes:
- build_tools.py: Enhanced find_test_root() to accept source_file_path parameter
  - Detects which module the source file belongs to (e.g., "server" from "server/src/main/...")
  - Returns that module's test directory (e.g., "server/src/test/java")
  - Falls back to existing behavior if source file not in a module

- function_optimizer.py: Updated _fix_java_test_paths() to use module-aware test root
  - Calls find_test_root() with source file path
  - Places generated tests in the correct module's test directory
  - Ensures `:server:test --tests` runs instead of `test --tests` (all modules)

This fixes optimization failures on multi-module Gradle projects where tests were
placed in the wrong location and couldn't be found by the build tool.

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
…vided

For multi-module Gradle projects, test_module parameter may be None when tests
are first generated. This adds fallback logic to detect the module by searching
for test classes in module directories, ensuring JaCoCo coverage files and test
execution use the correct module path.
Add fallback logic to detect module by globbing for test files when direct path
matching fails. This handles cases where test class names don't directly map to
file paths.
… projects

When tests_root is configured as 'server/src/test/java', extract 'server' as the
module name and pass it to test execution functions. This ensures:
- Correct JaCoCo .exec path (server/build/jacoco/test.exec)
- Correct --classfiles path for coverage XML conversion
- Correct Gradle task (:server:test instead of test)

Changes:
- verification_utils.py: Add java_test_module property to TestConfig
- test_runner.py: Pass java_test_module through all test functions
- support.py: Update wrappers to pass java_test_module
- function_optimizer.py: Pass test_cfg.java_test_module to test functions
@HeshamHM28 HeshamHM28 force-pushed the feat/java-gradle-support branch from e235cc1 to 5fe2cdf Compare February 4, 2026 00:18
Ubuntu and others added 3 commits February 4, 2026 00:18
Resolve conflict in function_optimizer.py by keeping module-aware test root
detection logic from feat/java-gradle-support branch.
Enhanced test file filtering to check for test-related patterns
(test, tests, __tests__, testFixtures) even when tests_root
doesn't overlap with source directories.

This fixes edge cases in Java/Gradle projects where:
- Files in src/main/test/ should be filtered as tests
- Files in src/testFixtures/ should be filtered as test fixtures

The previous logic only checked these patterns when tests_root
overlapped with source, missing these edge cases in multi-module
Java projects where tests are in separate directories.

Fixes test failures in test_filter_java_multimodule.py
… support

Refined test file filtering to maintain backward compatibility:

When tests_root overlaps with source (monorepo structure):
- Apply filename patterns (.test., .spec., _test., _spec.)
- Apply directory patterns (test, tests, __tests__, testFixtures)

When tests_root doesn't overlap (separate test directory):
- Check if file is under tests_root
- Apply directory patterns (test, tests, __tests__, testFixtures)
- Do NOT apply filename patterns (maintains original behavior)

This preserves the existing behavior for non-overlapping cases while
adding support for Java/Gradle edge cases like src/main/test/ and
src/testFixtures/.
@codeflash-ai
Copy link
Contributor

codeflash-ai bot commented Feb 4, 2026

⚡️ Codeflash found optimizations for this PR

📄 19% (0.19x) speedup for _validate_test_filter in codeflash/languages/java/test_runner.py

⏱️ Runtime : 794 microseconds 666 microseconds (best of 105 runs)

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

If you approve, it will be merged into this PR (branch feat/java-gradle-support).

Static Badge

HeshamHM28 and others added 2 commits February 4, 2026 10:19
Co-authored-by: codeflash-ai[bot] <148906541+codeflash-ai[bot]@users.noreply.github.com>
Resolved conflicts in:
- codeflash/version.py (kept gradle branch version)
- codeflash/languages/java/test_runner.py (kept gradle multi-module logic)
- codeflash/languages/java/support.py (kept java_test_module parameter)
- codeflash/discovery/functions_to_optimize.py (kept enhanced test filtering)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
@KRRT7 KRRT7 deleted the branch omni-java February 20, 2026 00:49
@KRRT7 KRRT7 closed this Feb 20, 2026
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.

3 participants