I had never needed to install Gradle before as all our projects have a bundled gradle wrapper, and the STS plugin “just worked”. The gradle wrapper uses v2.8.
Now I’ve switched to Buildship, attempting to run a unit test gives the error:
Launching Gradle Tests failed due to an error connecting to the Gradle build. The version of Gradle you are using (2.2) does not support the TestLauncher API. Support for this is available in Gradle 2.6 and all later versions.
Under Window > Preferences there is nothing to indicate how Buildship is locating the Gradle version to use.
I just installed Gradle 3.1 so it is now on the PATH and restarted Eclipse, but the error persists.
How does Buildship locate the Gradle installation to use? How can I change it if incorrect?
You don’t have to install anything manually. If you use the Gradle import wizard you’ll find the Gradle distribution selection on the second page. There, you have the option to use the Gradle wrapper from the project, or to use a specific Gradle version. In the latter case Buildship will download the distribution for you and associate it with your project.
Using the wrapper is the default in Buildship. So this should just work out of the box.
Maybe someone else on your team explicitly set version 2.2 and checked that configuration in? Please reimport the project and double-check on the second wizard page to be sure.
I am having just the same problem.
Gradle wrapper does not help.
It seems that it is actually starting the right Gradle version - I configured the wrapper for 3.1 in build.gradle, ran ./gradlew wrapper and verified the properties file, and indeed the command line in the final “Import Preview” wizard page matches that, as does the import wizard page which also says “Gradle version 3.1”, so all seems fine.
Still I am getting the same error about HierarchicalEclipseProject.getIdentifier(), see full error message and stack trace below.
I noticed one difference: for me, it is not reporting the Gradle version in the error message as it did for the OP.
P.S.: The import fails, Eclipse does not have a new project. IOW I cannot import Gradle projects anymore :-(((
P.P.S.: I am getting the same behaviour if reconfigure the Gradle wrapper for 3.2-rc3. I suspect Buildship 1.0.17.v20160713-1853 is incompatible with newer Gradle versions.
Which is funny since that’s the Buildship version I got when pulling it from Marketplace, on an Eclipse Neon which is just three months old.
(1) Command is jaa-8-openjdk-amd64/bin/java, parameters are -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -Xmx1024m -Dfile.encoding=UTF-8 -Duser.country=DE -Duser.language=de -Duser.variant -cp /home/jo/.gradle/wrapper/dists/gradle-3.1-bin/37qejo6a26ua35lyn7h1u9v2n/gradle-3.1/lib/gradle-launcher-3.1.jar org.gradle.launcher.daemon.bootstrap.GradleDaemon 3.1
(2) Error message and stack trace:
org.gradle.tooling.model.UnsupportedMethodException: Unsupported method: HierarchicalEclipseProject.getIdentifier().
The version of Gradle you connect to does not support that method.
To resolve the problem you can change/upgrade the target version of Gradle you connect to.
Alternatively, you can ignore this exception and read other information from the model.
at org.gradle.tooling.model.internal.Exceptions.unsupportedMethod(Exceptions.java:34)
at org.gradle.tooling.internal.adapter.ProtocolToModelAdapter$InvocationHandlerImpl.invoke(ProtocolToModelAdapter.java:342)
at com.sun.proxy.$Proxy41.getIdentifier(Unknown Source)
at com.gradleware.tooling.toolingmodel.repository.internal.DefaultOmniEclipseProject.from(DefaultOmniEclipseProject.java:251)
at com.gradleware.tooling.toolingmodel.repository.internal.DefaultOmniEclipseProject.from(DefaultOmniEclipseProject.java:247)
at com.gradleware.tooling.toolingmodel.repository.internal.DefaultOmniEclipseGradleBuild.from(DefaultOmniEclipseGradleBuild.java:46)
at com.gradleware.tooling.toolingmodel.repository.internal.DefaultSingleBuildModelRepository$8.apply(DefaultSingleBuildModelRepository.java:181)
at com.gradleware.tooling.toolingmodel.repository.internal.DefaultSingleBuildModelRepository$8.apply(DefaultSingleBuildModelRepository.java:177)
at com.gradleware.tooling.toolingmodel.repository.internal.BaseModelRepository.executeAndWait(BaseModelRepository.java:164)
at com.gradleware.tooling.toolingmodel.repository.internal.BaseModelRepository.access$000(BaseModelRepository.java:41)
at com.gradleware.tooling.toolingmodel.repository.internal.BaseModelRepository$2.call(BaseModelRepository.java:121)
at com.google.common.cache.LocalCache$LocalManualCache$1.load(LocalCache.java:4724)
at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3522)
at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2315)
at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2278)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2193)
at com.google.common.cache.LocalCache.get(LocalCache.java:3932)
at com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4721)
at com.gradleware.tooling.toolingmodel.repository.internal.BaseModelRepository.getFromCache(BaseModelRepository.java:138)
at com.gradleware.tooling.toolingmodel.repository.internal.BaseModelRepository.executeRequest(BaseModelRepository.java:117)
at com.gradleware.tooling.toolingmodel.repository.internal.BaseModelRepository.executeRequest(BaseModelRepository.java:88)
at com.gradleware.tooling.toolingmodel.repository.internal.DefaultSingleBuildModelRepository.fetchEclipseGradleBuild(DefaultSingleBuildModelRepository.java:185)
at org.eclipse.buildship.core.workspace.internal.DefaultModelprovider.fetchEclipseGradleBuild(DefaultModelprovider.java:53)
at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildsJob.synchronizeBuild(SynchronizeGradleBuildsJob.java:77)
at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildsJob.runToolingApiJob(SynchronizeGradleBuildsJob.java:69)
at org.eclipse.buildship.core.util.progress.ToolingApiJob$1.run(ToolingApiJob.java:73)
at org.eclipse.buildship.core.util.progress.ToolingApiInvoker.invoke(ToolingApiInvoker.java:63)
at org.eclipse.buildship.core.util.progress.ToolingApiJob.run(ToolingApiJob.java:70)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
In my case, the resolution was to upgrade Buildship from 1.0.17 to 1.0.21.
I conclude that the version dependencies between Buildship and Gradle should be documented.
I agree with you, this should be documented. We’ll think about where to put this information; any suggestion are welcome.
It’s weird that you got Buildship 1.0.17 from the marketplace, it should always give you the latest version. Can you reproduce it, or was it a one-time thing?
I don’t think we need special documentation. This was a bug on our side, Buildship should never have depended on that unstable API. Buildship 1.0.21 will work with all Gradle versions again.
Even better if Buildship is not supposed to depend on Gradle version
I got Buildship from the marketplace, not too long ago. I guess I was unlucky and the version that happened to be there at the time had that unwanted dependency.
If version independence works out, I agree with Stefan that it does not need to be documented.
However, it would be nice if accidental use of unstable APIs could somehow be prevented in the future.
