Cannot load Gradle project model from folder ...

[brunpoern]

I now tried to use the Language Server feature with a more complex example. The example project is part of a bigger Gradle multi-project build and in the Eclipse workspace there are also some unused pom.xml files (we migrated to Gradle recently). If I start Eclipse I get Spring Boot Java Language Server Error "Cannot load Gradle project model from folder: ...". Sometimes I also get the error "Cannot load Maven project model ..." where it picks a (random?) pom.xml file from my Eclipse workspace. I'm wondering what STS4/Language Server expects here. Does it really try to load my build files? The Eclipse projects itself doen't have any Maven/Gradle nature. We just generate Eclipse project files from Gradle and import them as normal Java Projects. Does STS4 require to have Gradle/Maven Eclipse projects or should it also work with "plain" Java projects?

In the Eclipse workspace log I get the following error but I'm not sure if it's related:

!ENTRY org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer 4 1000 2017-12-12 11:13:56.774
!MESSAGE Missing header Content-Length in input "
"
!STACK 0
java.lang.IllegalStateException: Missing header Content-Length in input "
"
at org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.listen(StreamMessageProducer.java:73)
at org.eclipse.lsp4j.jsonrpc.json.ConcurrentMessageProcessor.run(ConcurrentMessageProcessor.java:84)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

Should I create a new issue for this problem?

Thanks and regards,
Andreas

[brunpoern]

Reply from @BoykoAlex :

No it doesn't require Eclipse projects... Which Gradle version is being used by your project?
There is a limitation in the STS4 tooling related to Gradle projects at the moment (due to a bug in Gradle which was fixed for the latest Gradle version leaving us with limitations for older versions). Any chance you can point us to a git repo with your Gradle project(s) to try?
I'd say it's a separate issue. Unlikely to be Win specific.

[brunpoern]

No, it's the other way around. Our Eclipse projects are neither Gradle nor Maven projects (i.e. they are just plain Eclipse Java projects without any Gradle/Maven nature). But we have *.gradle and pom.xml files in our Eclipse workpsace (because we build with Gradle from the command line) but STS4 should just ignore them.

However for instance in BootPropertiesLanguageServerParams.java I can see that STS4 looks only for Gradle and Maven projects. So my assumption was that STS4 interprets our Eclipse projects as Gradle projects and tries to load the Gradle model but in my understanding this will fail because it doesn't know our project structure (e.g. it cannot find the root project, etc.).

From the command line we use Gradle 4.1 but we cannot use Buildship in Eclipse because we have a large number of projects and refreshing Gradle projects in Eclipse using Buildship is too slow. So we just generate plain Eclipse Java projects which we import in Eclipse but Eclipse doesn't have any knowledge that these projects are Gradle projects.

Unfortunately I cannot provide a public link because it's a closed source project.

To sum it up, does STS4 requires Gradle/Maven projects or should it also work with plain Eclipse Java projects? If it's still unclear I could try to convert my simple demo project (based on Maven where STS4 is working correctly) to a plain Java project and upload it.

[martinlippert]

@brunpoern That is the culprit, I think. At the moment the language server tries to resolve the classpath of a project by analyzing it for build tool files (pom.xml, build.gradle) and uses that build environment to resolve the classpath. But that doesn't seem to be right for your case, eh? Looks like our automatic way of finding out the "right" way to get a resolved classpath doesn't fit your case yet.

How does your project look like? Does it define all the dependencies (all the JAR files, etc.) manually in the project buildpath setup?

We could add support for dealing with .project setups from Eclipse for sure. In that case we would need to be smart about classpath containers in Eclipse, because we don't have them around in the language server. But if there is no classpath container being used in the project setup, reading stuff from the .project file could work. Thoughts?

[BoykoAlex]

STS4 only works with Maven and Gradle projects. It executes maven/gradle tooling code under the hood to determine the classpath of a project. In the Gradle case it attempts to build projects "Gradle Model" using Gradle Tooling API (used in Buildship Gradle and STS Gradle). The limitation of our Gradle tooling is that we attempt to load the "Gradle Model" with Gradle 4.3 distro.
Can you attach the full stack trace of the exception you're getting?

[kdvolder]

To sum it up, does STS4 requires Gradle/Maven projects or should it also work with plain Eclipse Java projects?

Essentially, yes, requires gradle/maven. And no it doesn't work with plain eclipse files. It looks for maven and gradle build files in the projects. The language servers are separate from Eclipse and don't really care about any of the eclipse metadata such as .project files, .classpath etc.

Relying on Eclipse metadata isn't as easy as it sounds because, for example, in its classpath files it uses things which rely on Eclipse infrastructure, such as classpath containers.

For your project, it sounds like maybe it would work properly if we found a workaround for the gradle issue. Though there is also still the issue that having both gradle and maven files around is likely to cause more things to go wrong/confused.

I understand you can't share your project, but maybe you could create a simpler sample that represents more or less what you are doing and show the bug? We don't have a good way of testing any solution we come up with at the moment, so that would really help.

[brunpoern]

Wow, replies from three different people nearly in parallel. I'm really feeling like a VIP :-) @martinlippert hits the point. We don't use any classpath containers in Eclipse. I can create a small demo project tomorrow but basically our Eclipse .project files looks like this:

<projectDescription>
	<name>foo</name>
	<comment></comment>
	<projects/>
	<natures>
		<nature>org.eclipse.jdt.core.javanature</nature>
	</natures>
	<buildSpec>
		<buildCommand>
			<name>org.eclipse.jdt.core.javabuilder</name>
			<arguments/>
		</buildCommand>
	</buildSpec>
	<linkedResources/>
	<filteredResources/>
</projectDescription>

And our .classpath files like this:

<classpath>
	<classpathentry kind="src" path="src/main/java"/>
	<classpathentry kind="src" output="bin/classes" path="src/test/java"/>
	<classpathentry kind="src" output="bin/classes" path="src/test/resources"/>
	<classpathentry kind="lib" path="<LOCAL_MAVEN_REPO>/javax/enterprise/cdi-api/1.2/cdi-api-1.2.jar" />
        ...

Actually we don't create these files by hand but generate them using Gradle but this doesn't matter. I understand that it should work if we would use Buildship to import our Gradle projects but the problem is that it's a multi-project build with ~200 sub-projects and refreshing these projects with Buildship tooks >10 min which means if I only modify one dependency in a sub-project I'm blocked for > 10min until I can continue working in Eclipse and that's why it's not really usable for us. So a solution like @martinlippert suggested just based on the dependencies defined in .project/.classpath would be great for us.

Splitting-up our build in smaller builds is not really an option for us at the moment because it would require too much effort. But we are working on it and migration to Spring Boot is a first step ;-)

[brunpoern]

I think now I got it. STS4 doesn't care how the projects are imported in Eclipse or how Eclipse handles the classpath. It just uses Eclipse to find the Gradle build files in the Eclipse workspace and then tries to load them. This sounds good because it means that it doesn't depend on Buildship. STS4 just has to understand our Gradle project structure and then I also have a rough idea what the problem is. Our Gradle root project is located in a specific folder which doesn't match the Gradle conventions, i.e. STS4 probably has no chance to find it. It only finds the Gradle build file in the Spring Boot sub-project and this cannot be loaded in isolation. If we run Gradle in the project directoy of a sub-project we always have to specify the location of the root project explicitly.

I will try to provide a simple example until tomorrow.

And this also means that we don't need a solution based on the Eclipse .project/.classpath files as suggested above. If STS4 could understand our Gradle project structure, this would be the much better solution.

Thanks again for the quick responses.

[kdvolder]

If STS4 could understand our Gradle project structure, this would be the much better solution.

Hmm... yes, except, maybe not so good because it might take > 10 minutes to analyze. As I take it, this is precisely why you don't use BuildShip. But if STS uses tooling api similar to buildship does, then it will encounter similar delays. I suppose it will be somewhat better than in Eclipse because the LS being a separate process will not stop you from actually doing other things while it is busy resolving classpath in background.

[brunpoern]

If I run the Gradle build from the command line it takes just seconds for a full analysis especially if the Gradle daemon is used and hot. I'm not sure why Buildship takes so much more time. It's already some time ago when I tried it the last time. But if I remember correctly the main issue was that Buildship always triggered a full rebuild in Eclipse which took most of the time. So I still have hope that it's much faster if STS4 just uses Gradle.

[brunpoern]

I have created a simple demo project to reproduce the error: https://github.com/brunpoern/sts4-example

You can import it in Eclipse using Buildship. The project structure doesn't follow the Gradle conventions because our root project (which also contains the settings.gradle) is located parallel to the sub-projects in the folder sts4-example-root.

If I import these projects in STS4 I get the mentioned error as notification:

[martinlippert]

Thanks for attaching the sample project, I will add this to our items for the next update... :-)

[martinlippert]

We have changed the way projects are resolved for a very long time now, but I somehow missed to update this item. Apologizes for that.

Nowadays we get the project structure from the Java tooling around us (the Eclipse IDE or the Java tooling inside of VSCode) to determine the projects and their classpaths. Therefore the underlying issue here should be solved already for a long time. Therefore I am closing this one here now.

If you come across a similar issue using the latest Spring Tools 4, please open a new issue and we will investigate.