Replace shell-based task commands with Rust proxy subcommands

[drmaniac]

After I missed the feature of running Java tasks in multi modules java projects I have enhanced the tasks.json commands (Heavy Shell script in a single line). (see #244)

So I have make up my minds and would suggest to move the logic from tasks.json to Rust code.

So my design Idee is:

1. Extend java-lsp-proxy with Task Subcommands

Add a new module to the proxy (proxy/src/task.rs) that provides CLI subcommands:

java-lsp-proxy task run-class <file> <package> <class> [outer_class]
java-lsp-proxy task run-test-method <file> <package> <class> [outer_class] <method>
java-lsp-proxy task run-test-class <file> <package> <class> [outer_class]
java-lsp-proxy task run-all-tests <file>
java-lsp-proxy task clear-cache

Each command outputs JSON to stdout with the resolved command + arguments:

{
  "command": "/usr/bin/mvn",
  "args": ["clean", "test", "-pl", "backend", "-Dtest=com.example.MyTest"],
  "cwd": "/path/to/workspace"
}

2. Main Module Structure (proxy/src/task.rs)

// Core functions the Rust side handles:

enum BuildTool {
    Maven,
    Gradle,
    None,
}

fn detect_build_tool(file_path: &str) -> BuildTool {
    // Walk up from file to workspace root
    // Check for pom.xml (Maven) or build.gradle* / settings.gradle* (Gradle)
}

fn find_closest_module(file_path: &str, is_maven: bool) -> PathBuf {
    // Walk up from file's directory finding nearest pom.xml or build.gradle*
    // Returns the module directory path
}

fn which_wrapper(tool: &str) -> String {
    // Prefer ./mvnw or ./gradlew in CWD, fall back to PATH
}

struct TaskCommand {
    command: String,
    args: Vec<String>,
    cwd: String,
}

3. Each Task Handler

run-class (replaces the java-main tag):

fn task_run_class(file: &str, package: &str, class: &str, outer: Option<&str>) -> TaskCommand {
    let full_class = match outer {
        Some(o) => format!("{}.${}", class, o),
        None => class.to_string(),
    };
    let full_name = if package.is_empty() { full_class } else { format!("{}.{}", package, full_class) };
    
    match detect_build_tool(file) {
        BuildTool::Maven => {
            let module = find_closest_module(file, true);
            let cmd = which_wrapper("mvn");
            // mvn clean compile exec:java -Dexec.mainClass=...
            // or: mvn clean compile -pl module -am && mvn exec:java -pl module ...
        }
        BuildTool::Gradle => {
            let module = find_closest_module(file, false);
            let cmd = which_wrapper("gradle");
            // gradle :module:run -PmainClass=...
        }
        BuildTool::None => {
            // javac + java fallback
        }
    }
}

run-test-method (replaces java-test-method / java-test-method-nested) run-all-tests: Same pattern without class/method filtering.:

fn task_run_test_method(file: &str, package: &str, class: &str, outer: Option<&str>, method: &str) -> TaskCommand {
    // Similar structure, constructs:
    // Maven: mvn test -Dtest="package.Class#method"
    // Gradle: gradle test --tests "package.Class.method"
}

clear-cache:

fn task_clear_cache() -> TaskCommand {
    // Detect cache dir: XDG_CACHE_HOME, ~/Library/Caches, or ~/.cache
    // Construct: rm -rf ~/.cache/jdtls-*
}

4. Wire into main.rs

fn main() {
    let args: Vec<String> = env::args().skip(1).collect();
    
    // New: handle task subcommands
    if args.first().map(|a| a == "task").unwrap_or(false) {
        task::handle_task(&args[1..]);
        return;
    }
    
    // Existing: LSP proxy mode
    // ...
}

5. Simplified tasks.json

Current (complex shell):

"command": "pkg=\"$ZED_CUSTOM_java_package_name\"; cls=\"$ZED_CUSTOM_java_class_name\"; ... 200 chars of shell ..."

After (thin wrapper):

{
    "label": "Run $ZED_CUSTOM_java_class_name",
    "command": "ZED_EXT=\"${XDG_DATA_HOME:-$HOME/.local/share}/zed/extensions/work/java/proxy-bin\"; [ \"$(uname)\" = \"Darwin\" ] && ZED_EXT=\"$HOME/Library/Application Support/Zed/extensions/work/java/proxy-bin\"; PROXY_BIN=$(find \"$ZED_EXT\" -type f -name \"java-lsp-proxy*\" | sort | tail -n 1); $PROXY_BIN task run-class \"$ZED_FILE\" \"$ZED_CUSTOM_java_package_name\" \"$ZED_CUSTOM_java_class_name\" \"${ZED_CUSTOM_java_outer_class_name:-}\"",
    "tags": ["java-main"],
    "shell": { "with_arguments": { "program": "/bin/sh", "args": ["-c"] } }
}

Benefits

Aspect	Before (Shell)	After (Rust)
Build tool detection	Duplicated shell loops	Single Rust implementation
Module resolution	Duplicated shell loops	Single Rust implementation
Command construction	Hard to read shell	Type-safe Rust structs
Testing	Manual shell testing	Unit tests in Rust
Cross-platform	Shell quirks	Rust handles platforms
Maintainability	5 nearly-identical scripts	1 Rust module

[tartarughina]

I love the idea, we lose the customization of the current tasks but maintaining them improves ten folds.

Based on this, #244 should be momentarily put on pause so that we avoid repeated work and ship a single feature all together.
Let me know if you're against this decision or if #244 should just introduce the infra for task testing.

Also, it doesn't really need to be bound to the proxy, we can have another module whose only purpose is task management.
It will require downloading an additional binary but the code separation is worth it. Following this, the test infra included in #244 could be moved in this submodule as well to keep things tidy and separated.

[gayanper]

I vote 👍 for this idea.

I have a multimodule java project where there are tests in each module. Given the current version of zed java extension expect flat single module java projects, I was not able to use it out of the box to run java tests.

The project is a gradle project, So I was able to write simple init plugin to resolve closest module and rewrite task name to use correct module prefix so that gradle properly loads the project and it's dependencies with the current version of task runner.

But with this suggested approach, we can add more such logic inside the lsp proxy.

I would also assume that we can even provide support to debug tests with a task like Zed javascript jest task does.

If needed I can provide help where it is necessary since I have some experience working in jdtls and jdt DAP components

[drmaniac]

I agree with the feedback. To balance immediate needs with long-term maintainability, I suggest the following two-step approach:
First proceed with the #244 PR to bring multi-module support to users now (From my perspective it looks complete).
Second I could start to "Rustify" the logic into the proxy task. Then we could keep in mind @gayanper suggestion to add debugger features as well (Run Tests in debug mode) based on the rust task foundation.

[gayanper]

I agree with the feedback. To balance immediate needs with long-term maintainability, I suggest the following two-step approach:
First proceed with the #244 PR to bring multi-module support to users now (From my perspective it looks complete).
Second I could start to "Rustify" the logic into the proxy task. Then we could keep in mind @gayanper suggestion to add debugger features as well (Run Tests in debug mode) based on the rust task foundation.

💯 onboard. Providing the multi module immediately with what is available is a great win from end user point of view.

[tartarughina]

@drmaniac @gayanper I've merged #244 and the new release is in Zed's queue waiting to be merged and made available on the marketplace

[playdohface]

@drmaniac @gayanper is someone currently working on this? If not I could get us started, this is a great idea and at the moment I don't see why it wouldn't work, but I'll only find out once I tried

[drmaniac]

@playdohface I didn't have too much time in the past but I have started a branch rustify-tasks (WIP).
If someone with more time wants to take it over, it is fine from my side. The last thing I was looking at was to add debug tasks, but there I didn't find out how to do it.

I have tatest this with some own gradle and maven projects (single/multi module).

[playdohface]

@drmaniac I just had a look at this, secretly hoping this might open up #94 without requiring upstream changes in zed but unfortunately we still need shell logic to find the extension work dir (i.e. the proxy executable). It's still better to be able to define the tasks in Rust code rather than some messy shell-script-in-a-json-string so I am all for this anyway.
There's no rush, feel free to open a PR with your changes and we can move things forward from there

[drmaniac]

Hi everyone,

Building on top of the original PR for rustifying tasks, I have developed a branch (build-tool-test-debug-support) that implements test execution and debugging directly supported by the project's build system (Maven/Gradle).

How it works:

1. DAP Locator Integration: It uses Zed's extension API hooks (run_dap_locator and dap_locator_create_scenario) to intercept test execution.
2. Build-System Delegation: Instead of utilizing JDTLS to compile, package, and launch debugging sessions, the java-task-helper directly invokes the build system (gradlew or mvn) with the appropriate JVM debugging flags (-agentlib:jdwp=... or Gradle init scripts for debugOptions).
3. Direct Attachment: The target test process starts suspended and listens on a JDWP port, and Zed attaches its debugger adapter (vscode-java-debug) directly to that port.

Benefits:

• No JDTLS Dependency for Runs/Debugs: This keeps dependency management, classpath resolution, compilation, and environment configurations entirely under the control of the build system itself. This avoids synchronization issues and failures often caused by JDTLS attempting to manage classpath/dependencies for complex or multi-module projects.

This implementation is currently in a draft state on my branch. I wanted to ask if this approach of bypassing JDTLS for running/debugging tests and relying directly on the build system goes in the right direction for the extension?

I would appreciate any feedback or suggestions on this design!

[playdohface]

@drmaniac At first glance I'm not convinced this last proposal is a great idea by premise.
First, the synchronization issues, do we see people actually experiencing them or do you? If so, I'd like to better understand the actual problem before solving it.
Second, depending on the build system here is quite brittle. Gradle and Maven are both fickle beasts, and I imagine getting them to behave consistently comes with a long tail of complexity, provided they are even present. JDTLS on the other hand we download and launch ourselves, and while it's not perfect at least it's a known value, so I struggle to see the benefit

[tartarughina]

Closing the issue as tasks have been moved to task-helper in #274