feat: Add comprehensive Gradle build tool support for Java#1319
Closed
HeshamHM28 wants to merge 14 commits intoomni-javafrom
Closed
feat: Add comprehensive Gradle build tool support for Java#1319HeshamHM28 wants to merge 14 commits intoomni-javafrom
HeshamHM28 wants to merge 14 commits intoomni-javafrom
Conversation
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>
|
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. |
…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
e235cc1 to
5fe2cdf
Compare
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/.
Contributor
⚡️ Codeflash found optimizations for this PR📄 19% (0.19x) speedup for
|
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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)
--testsflag:server:test)Multi-Module Support (test_runner.py)
settings.gradleandsettings.gradle.ktsfilesincludestatements--testsformatTest Coverage
Added comprehensive test suite with 21 tests in
test_gradle_support.py:All tests passing: 21/21 ✅
Testing
Unit Tests
Integration Testing (Elasticsearch)
Tested on Elasticsearch repository (multi-module Gradle project):
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:
Implementation Notes
Gradle Test Filtering
Gradle uses a different test filtering syntax than Maven:
com.example.TestClass#testMethod--tests com.example.TestClass.testMethodThe implementation converts between these formats automatically.
Multi-Module Support
For multi-module projects, the implementation:
settings.gradlefile:module:test)Coverage Collection
JaCoCo integration for Gradle:
test jacocoTestReporttasksbuild/reports/jacoco/test/jacocoTestReport.xml🤖 Generated with Claude Code