search

redhat-developer / vscode-java

Java Language Support for Visual Studio Code
Eclipse Public License 2.0
2.08k stars 442 forks source link

IntelliSense provided by this extension no longer work when the workspace includes `build.gradle` #2682

Open tschaffter opened 2 years ago

tschaffter commented 2 years ago

My team is developing in an Nx monorepo with VS Code where apps and libraries are listed in the folder apps/ and libs. Some of our apps and libs are in Java. We installed the Extension Pack for Java, which include this extension (Language Support for Java(TM) by Red Hat). Java projects are built with either Maven or Gradle. In this context, this VS Code extension works great as language support for Java. For example, IntelliSense works properly in VS Code for Java files.

I observed that this extension breaks when placing the file build.gradle in the workspace root folder. By breaking, I mean that IntelliSense is no longer working. See this issue for more detailed information and logs. The issue is related to the presence of the file build.gradle as an empty file still breaks the language support. Having a workspace-level build.gradle is a standard for multi-project build.

The expected behavior is that this VS Code extension should work fine in the context of multi-project build with Gradle.

Environment
Steps To Reproduce
  1. Clone this repo: https://github.com/Sage-Bionetworks/challenge-registry.git
  2. Checkout the commit 4e63ff1e150337882b680f05bf25c81bffa0fdfc
  3. Follow the README to setup the project
  4. Open a .java file > IntelliSense does not work
  5. Delete the file build.gradle
  6. Repeat Steps 3
  7. Open a .java file > IntelliSense works

Detailed logs can be found here.

Current Result

IntelliSense does not work in Java files. For example, no tooltip is displayed in VS Code when hovering on an import statement.

Expected Result

IntelliSense should work in Java files.

Additional Informations
$ nx report

 >  NX   Report complete - copy this into the issue template

   Node : 16.17.0
   OS   : linux x64
   yarn : 3.2.2

   nx : 14.5.4
   @nrwl/angular : 14.5.4
   @nrwl/cypress : 14.5.4
   @nrwl/detox : Not Found
   @nrwl/devkit : 14.5.4
   @nrwl/eslint-plugin-nx : 14.5.4
   @nrwl/express : Not Found
   @nrwl/jest : 14.5.4
   @nrwl/js : 14.5.4
   @nrwl/linter : 14.5.4
   @nrwl/nest : Not Found
   @nrwl/next : Not Found
   @nrwl/node : 14.5.4
   @nrwl/nx-cloud : 14.3.0
   @nrwl/nx-plugin : 14.5.4
   @nrwl/react : Not Found
   @nrwl/react-native : Not Found
   @nrwl/schematics : Not Found
   @nrwl/storybook : 14.5.4
   @nrwl/web : 14.5.4
   @nrwl/workspace : 14.5.4
   typescript : 4.7.4
   ---------------------------------------
   Community plugins:
         @nguniversal/express-engine: 14.2.0
         @nguniversal/builders: 14.2.0
         @nx-tools/nx-docker: 2.3.0
         @nxrocks/nx-spring-boot: 5.0.2
$ code --list-extensions --show-versions
Extensions installed on Dev Container: Challenge @ ssh://devcontainers-ssm:
1000ch.svgo@2.8.1
Angular.ng-template@14.2.0
dbaeumer.vscode-eslint@2.2.6
emeraldwalk.RunOnSave@0.2.0
esbenp.prettier-vscode@9.8.0
firsttris.vscode-jest-runner@0.4.56
GabrielBB.vscode-lombok@1.0.1
GitHub.vscode-pull-request-github@0.50.0
humao.rest-client@0.25.1
mhutchie.git-graph@1.30.0
mongodb.mongodb-vscode@0.9.3
ms-azuretools.vscode-docker@1.22.1
ms-python.python@2022.14.0
ms-python.vscode-pylance@2022.9.20
ms-toolsai.jupyter@2022.8.1002431955
ms-toolsai.jupyter-keymap@1.0.0
ms-toolsai.jupyter-renderers@1.0.9
mtxr.sqltools@0.25.1
mtxr.sqltools-driver-mysql@0.4.0
mtxr.sqltools-driver-pg@0.3.0
nrwl.angular-console@17.22.0
Pivotal.vscode-boot-dev-pack@0.1.0
Pivotal.vscode-spring-boot@1.39.0
redhat.java@1.10.0
richardwillis.vscode-spotless-gradle@1.2.1
ritwickdey.LiveServer@5.7.9
shengchen.vscode-checkstyle@1.4.1
stkb.rewrap@1.16.3
VisualStudioExptTeam.vscodeintellicode@1.2.27
vscjava.vscode-gradle@3.12.4
vscjava.vscode-java-debug@0.44.0
vscjava.vscode-java-dependency@0.21.0
vscjava.vscode-java-pack@0.25.1
vscjava.vscode-java-test@0.37.1
vscjava.vscode-maven@0.38.0
vscjava.vscode-spring-boot-dashboard@0.7.0
vscjava.vscode-spring-initializr@0.11.0
webhint.vscode-webhint@2.1.3
jdneo commented 2 years ago

Why not put the build.gradle under apps and meanwhile, add settings.gradle under apps to declare all your sub-modules?

snjeza commented 2 years ago

@tschaffter You can try the following:

$ cd challenge-registry
$ rm gradlew gradlew.bat

or

$ cd challenge-registry
$ cp -a libs/shared-java/challenge-util/gradle .
tschaffter commented 2 years ago

Why not put the build.gradle under apps and meanwhile, add settings.gradle under apps to declare all your sub-modules?

I'm relatively new to Gradle so not sure how this would work. Related to that I saw that there is a property buildFile that can be specified in settings.json to specify the location of build.gradle. However, specifying the location of a build file seems deprecated.

@snjeza I'm not sure how these two suggestions could help. Also, the presence of either gradlew or gradlew.bat in the workspace root folder was a condition for the activation of the VS Code extension Spotless Gradle that I used until recently.

I found a satisfying workaround that eliminates my need of having build.gradle in the workspace folder (see https://github.com/Sage-Bionetworks/challenge-registry/pull/724). However, the issue remain that this language support extension may break for developers who work on projects that include a build.gradle in the workspace folder.

snjeza commented 2 years ago

@snjeza I'm not sure how these two suggestions could help. Also, the presence of either gradlew or gradlew.bat in the workspace root folder was a condition for the activation of the VS Code extension Spotless Gradle that I used until recently.

You have installed a gradle wrapper partially and Java LS crashes. You have the valid gradle wrapper in the libs/shared-java/challenge-util project. You should just copy it.

tschaffter commented 2 years ago

Thanks @snjeza. I indeed forgot to commit the folder gradle in the commit I referenced earlier. However, I usually included this folder in my setup. To clarify, Java LS breaks with the following files in my workspace folder:

$ git status -u    
On branch test-gradle-setup
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        build.gradle
        gradle/wrapper/gradle-wrapper.jar
        gradle/wrapper/gradle-wrapper.properties
        gradlew
        gradlew.bat

nothing added to commit but untracked files present (use "git add" to track)
snjeza commented 2 years ago

@tschaffter You can skip the gradle importer using

"java.import.gradle.enabled": false,
jdneo commented 2 years ago

I'm relatively new to Gradle so not sure how this would work. Related to that I saw that there is a property buildFile that can be specified in settings.json to specify the location of build.gradle. However, specifying the location of a build file seems deprecated.

settings.json is used to persist VS Code's settings. AFAIK, we haven't expose any setting to specify the build.gradle location.

ZantsuRocks commented 6 months ago

Is there some workaround for this issue? My build.gradle is on root and src folder is on root too, this is a single "module" project and i prefer this way. With this configuration it's impossible to use intellisense in java files.