Skip to content
This repository has been archived by the owner on Dec 15, 2022. It is now read-only.

Classpath is incomplete from 0.6.4 #37

Closed
ppettit opened this issue Oct 6, 2017 · 8 comments
Closed

Classpath is incomplete from 0.6.4 #37

ppettit opened this issue Oct 6, 2017 · 8 comments

Comments

@ppettit
Copy link

ppettit commented Oct 6, 2017

With 0.6.0 I was using ide-java with no issues (other than the auto complete bug #10 and taking 4 minutes for JDT to start up) with a big maven project.

0.6.1-3 didn't work due to #30
0.6.4-5 give me the "Classpath is incomplete" dialog

I guess the change from Eclipse JDT 0.3 to 0.5 has broken something?

There are no errors in the dev console. Tried with Atom 1.21 and 1.22.

@damieng
Copy link
Contributor

damieng commented Oct 10, 2017

If you click the help link in the dialog that displays it will display information about what this error means and how to resolve it - basically it needs to find the build files. You need to open the folder at the right level for it to do this.

@n00dl3
Copy link

n00dl3 commented Oct 11, 2017

I have the same problem though I open a folder containing a pom.xml (and of course, the edited file is part of the current project).
2017-10-11-110053_956x505_scrot

  • JAVA_HOME is set in both env variables and the plugin settings.
  • running Debian stable
  • ide-java@0.6.5
  • atom-ide-ui@0.5.0
  • atom@1.21.0

@ppettit
Copy link
Author

ppettit commented Oct 11, 2017

I read the page, but that does not help as the project has a pom.xml file in the root just as @n00dl3 commented above.

Also, as mentioned, it works fine with ide-java 0.6.0. just downgrading the package with apm and restarting atom makes it work again.

Anything else I can try?

@tylerFowler
Copy link
Contributor

Had the same issue, is there any way to enable verbose logging? As mentioned nothing is logged to the atom console so I'm not even sure where to start troubleshooting short of cleaning & reinstalling.

Same though with downgrading to v0.6.0, that seems to work.

@remigastaldi
Copy link

Same issue but downgrading to v0.6.0 give me "Uncaught Error: Header must provide a Content-Length property."

@ajoberstar
Copy link

I've been researching this one as well because I haven't gotten a single Gradle project to work. From what I'm finding, you should always get incomplete classpath for all Maven and Gradle projects.

The offending commit in ide-java being the upgrade of the Eclipse JDT. Though technically, this is really an issue of mismatching LSP usage between atom-languageclient and the Eclipse JDT LS.

Issue

  • The language server protocol defines both a rootUri and rootPath that can be passed in during initialize. As of LSP 3.0 rootPath is deprecated in favor of rootUri.
  • The Eclipse JDT Server uses rootUri (and currently ignores rootPath) to determine your project's root, which is where it scans for the presence of build.gradle or pom.xml to support Gradle and Maven projects.
  • atom-languageclient has an InitializeParams type which only supports a rootPath.

As a result, JDT never sees the root of your project and just sets up a barebones Java project.

Proposed Solutions

Both of these changes should probably happen, but either one would fix ide-java (once ide-java upgrades to the new versions of these dependencies).

  • atom-languageclient should pass both rootPath and rootUri (as vscode-languageclient does)
  • Eclipse JDT should check both rootPath and rootUri (only using rootPath, if rootUri is null)

I'll open issues for both of these and hopefully one or both will be resolved.

Research

JDT LS Log

from %TEMP%\atom-java-<encoded project path>\.metadata\.log

!ENTRY org.eclipse.jdt.ls.core 1 0 2017-10-22 12:05:40.176
!MESSAGE >> initialize

!ENTRY org.eclipse.jdt.ls.core 1 0 2017-10-22 12:05:40.178
!MESSAGE Initializing Java Language Server 0.5.0.201709251422

!ENTRY org.eclipse.jdt.ls.core 1 0 2017-10-22 12:05:40.178
!MESSAGE No root uri was defined. Falling back on C:\Users\andre\AppData\Local\Temp\atom-java-C%3A%5Cusers%5Candre%5Cprojects%5Creckon%5C

Key message being no root uri was defined

atom-languageclient

Enabling core.debugLSP in Atom config gives messages showing the communication between Atom and the language server as console logs in developer tools.

Java (Eclipse JDT) rps.sendRequest initialize sending
Object
  ...
  rootPath: "C:\users\andre\projects\reckon\"
  ...

atom-languageclient sends this intialization message itself by default (ide-java has not overriden this) in getInitializeParams. The InitializeParams type, also part of atom-languageclient, specifies only the rootPath as an option.

Eclipse JDT

In the 0.5.0 JDT currently being used, that no root uri message occurs here. Above that line you can see it checking InitializeParams#getRootUri() to determine the root URI.

Notably, Atom is sending rootPath and JDT is checking rootUri. This JDT commit changed logic in 0.1.0 that used to check both rootPath and rootUri. This behavior is still true in master of JDT.

Between 0.6.0 and 0.6.1 of ide-java, The JDT dependency went from an old not final 0.1.0 (from April) to 0.3.0 (and has since moved beyond that version).

LSP4J

IntializeParams is part of LSP4J.

Currently LSP4J 0.3.0 is being used by JDT. InitializeParams shows both a rootUri and a rootPath (`rootPath being deprecated). That deprecation was introduced in a commit targeting compatilbility with LSP 3.0.

Language Server Protocol

LSP 3.0 indicates that rootDir has been deprecated in favor of rootUri and that if both are defined, rootUri wins.

@damieng
Copy link
Contributor

damieng commented Oct 22, 2017

Thanks for researching this!

I was trying to hold off LSP 3.0 support and there wasn't any indication the new language server was breaking 2.0 support.

I can add support for passing both as a subset of 3.0 support for now.

@damieng
Copy link
Contributor

damieng commented Oct 22, 2017

Fixed in 0.6.6! Sorry for the delay.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants