eclipse.jdt.ls icon indicating copy to clipboard operation
eclipse.jdt.ls copied to clipboard

eclipse.jdt.ls doesn't respect Gradle output directory

Open dradtke opened this issue 5 years ago • 7 comments

Gradle by default uses build as its output directory, and Eclipse uses bin, but it doesn't look like there's a way to tell the language server to use Gradle's settings without installing a separate Eclipse plugin. This has caused me problems when updating resources; the processResources task copies files over to build, but the language server can't see them because it's using bin.

dradtke avatar Apr 01 '20 15:04 dradtke

Gradle support is provided by the Buildship project. Separating the output directories of Eclipse and CLI builds is a design decision, basically to prevent conflicts between IDE and CLI builds. More about here: https://discuss.gradle.org/t/eclipse-plugin-did-not-configure-default-output-directory-to-build/7586.

Adding @rubensa's comment from https://github.com/redhat-developer/vscode-java/issues/1187#issuecomment-577217026 :

I ended with this configuration in my build.gradle so gradle build on "build/gradle" and eclipse on "build/eclipse":

buildDir = "build/gradle"
apply plugin: 'java'
apply plugin: 'eclipse'
eclipse {
  classpath {
    defaultOutputDir = file('build/eclipse')
    file.whenMerged {
      entries.each { entry ->
        if (entry.kind == 'src' && entry.hasProperty('output')) {
          entry.output = entry.output.replace('bin/', "build/eclipse/")
        }
      }
    }
  }
}

fbricon avatar Apr 01 '20 15:04 fbricon

That makes sense, but wouldn't it also make sense for the language server to override Buildship's default setting? Users of the server will be working with Gradle (or whatever the build system is) and not Eclipse directly.

dradtke avatar Apr 01 '20 16:04 dradtke

to prevent conflicts between IDE and CLI builds.

This applies to jdt.ls clients too, they're the IDEs, they will see the conflicts

fbricon avatar Apr 01 '20 16:04 fbricon

Is there a language server command for refreshing the build that I'm not aware of? I ran into this issue because I was running tests through java-debug, one failed due to an issue in a resource file, and the language server didn't pick up the resource change once I fixed it. The test kept failing until I either restarted the language server, or ran processResources and manually copied resources from build over to bin.

dradtke avatar Apr 01 '20 16:04 dradtke

Any solution or workaround for this problem. We use Gradle at work and Emacs fails to dap-debug for example as it searches for classes in the bin directory. I am not sure what else fails - perhaps it runs slower. Anyway, I managed to workaround the dap-debug problem by manually copying from build to bin, while respecting the destination locations. I'm considering automating the copy. Apart from that do you have any concerns/suggestions regarding this approach?

yotkamen avatar Apr 06 '21 06:04 yotkamen

Yeah, there's a poorly-documented command java/buildWorkspace, which helps in my case, as long as I forced a full rebuild.

dradtke avatar Apr 10 '21 03:04 dradtke

related to https://github.com/eclipse/buildship/issues/1131

CsCherrYY avatar Apr 13 '22 03:04 CsCherrYY