Gradle produces for dependency resolve errors using the Tooling API

If I have a dependency in build.gradle that doesn’t resolve the error produced via running the ‘grails’ command is which uses the Gradle Tooling API: org.gradle.api.internal.artifacts.DefaultModuleVersionSelector
at org.gradle.tooling.internal.provider.PayloadSerializer.serialize(
at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(
at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(
at org.gradle.launcher.daemon.server.exec.ExecuteBuild.doBuild(

If I use the ‘gradle’ command then the error is:

FAILURE: Build failed with an exception.
  • What went wrong:
    Could not resolve all dependencies for configuration ‘:runtime’.

Could not find org.grails.plugins:scaffolding:3.0.3.BUILD-SNAPSHOT.
Searched in the following locations:
Required by:

Which is much more helpful, can the Tooling API please produce the same error?

This relates to

Thanks, this looks like a regression introduced in 2.4.

I raised

Hey Gaeme,

Looking at this a little more, it looks like this is older than 2.4 (2.3 also does it and the class that’s not serializable hasn’t been for a couple of years). I think what you’re seeing is a failure coming out of a build action you’re supplying when resolving the GrailsClasspath model.

The exception comes up through the tooling api, we wrap the exception and then try to serialize it. This sort of thing would happen with any non-serializable exception coming through a ToolingModelBuilder or BuildAction, I believe.

As a workaround, you could catch the ResolveException in your GrailsClasspathToolingModelBuilder or handle the case of unresolved dependencies explicitly. Then you can throw something more helpful (e.g., something useful for what it means to fail to resolve the GrailsClasspath). This would get around your immediate problem and work with older Gradle tooling API’s.

We need to do some work to make the cause more obvious and see if we can handle these sorts of things better.

Thanks for finding this!

This is the best I could come up with:

Rethrowing any exception results in the same NotSerializableException from the Tooling API