Gradle 1.11 fails with Could not create task of type 'Help'

(Scott Palmer) #1

I have a complex project that runs fine with Gradle 1.10 and fails with Gradle 1.11 It is an older build script that makes use of GradleLauncher to run a some child builds. One of these fails with a cryptic message:

FAILURE: Build failed with an exception.

  • What went wrong: A problem occurred configuring root project ‘build’.

Could not create task of type ‘Help’.

I don’t know where that comes from. None of our scripts reference any task of type ‘Help’. The stack trace only seems to indicate that the sub-process used to run the child build failed.

This is the method I’m using to run the child builds:

void runSubGradle( Collection tasks ) {

println “******* Calling Gradle Launcher ${} $project.projectDir - $tasks ************”

def startParameter = project.gradle.startParameter.newBuild();

startParameter.setTaskNames( tasks )


startParameter.setProjectDir( projectDir );

startParameter.setCurrentDir( projectDir );

def subLauncher = GradleLauncher.newInstance(startParameter);

def result =;



And this is the stack trace when it fails:

org.gradle.api.tasks.TaskExecutionException: Execution failed for task ‘:MyProject:allRelease’.

at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(

at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(

at org.gradle.api.internal.tasks.execution.PostExecutionAnalysisTaskExecuter.execute(

at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(

at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(

at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(

at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(

at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(

at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(

at org.gradle.api.internal.AbstractTask.executeWithoutThrowingTaskFailure(

at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.executeTask(

at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.processTask(

at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$

at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor.process(

at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter.execute(

at org.gradle.execution.SelectedTaskExecutionAction.execute(

at org.gradle.execution.DefaultBuildExecuter.execute(

at org.gradle.execution.DefaultBuildExecuter.access$200(

at org.gradle.execution.DefaultBuildExecuter$2.proceed(

at org.gradle.execution.DryRunBuildExecutionAction.execute(

at org.gradle.execution.DefaultBuildExecuter.execute(

at org.gradle.execution.DefaultBuildExecuter.execute(

at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(

at org.gradle.initialization.DefaultGradleLauncher.doBuild(


at org.gradle.launcher.exec.InProcessBuildActionExecuter$



at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(

at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(


at org.gradle.internal.Actions$RunnableActionAdapter.execute(

at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(

at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(

at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(

at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(

at org.gradle.launcher.cli.ExceptionReportingAction.execute(

at org.gradle.launcher.cli.ExceptionReportingAction.execute(

at org.gradle.launcher.Main.doAction(


at org.gradle.launcher.Main.main(

at org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(


at org.gradle.launcher.GradleMain.main( Caused by: org.gradle.process.internal.ExecException: Process ‘command ‘C:\Windows\system32\cmd.exe’’ finished with non-zero exit value 1

at org.gradle.process.internal.DefaultExecHandle$ExecResultImpl.assertNormalExitValue(

at org.gradle.process.internal.DefaultExecAction.execute(

at org.gradle.api.tasks.Exec.exec(

at org.gradle.internal.reflect.JavaMethod.invoke(

at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.doExecute(

at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.execute(

at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.execute(

at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(

at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(

at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(

at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(

… 43 more


The ‘Help’ task will be executed if no build script is found, and if no tasks are supplied on the command line. (You can see this if you run ‘gradle’ in an empty directory).

I’m not aware of any changes to GradleLauncher that would have triggered this breakage. Can you try to isolate the actual sub-build that is failing? The fact that the message is “A problem occurred configuring root project ‘build’” makes me suspicious. The output of the println statement you have in you ‘runSubGradle’ method might be useful.

We’ll probably need the debug output and exception stack trace from the failing sub-build: the stack trace you provided simply indicates that a sub-build failed to execute.

(Scott Palmer) #3

The message configuring root project ‘build’ is correct… the main build is creating a new project as part of it’s output, which is why the gradle script that is executed next is in the “build” folder. The build script that is in the build folder was simply copied in from another location.

The println output showed the correct list of tasks:

******* Calling Gradle Launcher build C:\path_to_original_project\build - [installPluginXml, installGeneratedPluginSource, installPluginLicenses] ************

I will try to get more details when I have a chance to flip back to 1.11

(Scott Palmer) #4

How can I get the sub-build to produce a stack trace or debug output? I thought that by creating the start parameters from the main build parameters, as is done in my runSubGradle method, that it might propagate the --debug --stacktrace options. That apparently is not the case, and looking at the docs for both GradleLauncher and StartParameters, I can’t see how to do it.

I don’t know why this broke, but rather than fight it, I decided to convert to the Tooling API.

That solves the problem, but I noticed something odd. Even though I am running the main build with 1.11 when it hit this part of the build I saw a message about downloading Why would it need to do that? I didn’t specify anything to force the use of a particular version of Gradle and it was already running with 1.11.

******* Calling Gradle Launcher build C:\Users\scott.palmer\dev\Kayak\KayakCore\KayakCorePlugin\build - [installPluginXml, installGeneratedPluginSourc e, installPluginLicenses] ************ Downloading … … Unzipping C:\Users\scott.palmer.gradle\wrapper\dists\gradle-1.11-bin\4h5v8877arc3jhuqbm3osbr7o7\ to C:\Users\scott.palmer.gradle\w rapper\dists\gradle-1.11-bin\4h5v8877arc3jhuqbm3osbr7o7 09:48:00.870 [Connection worker] DEBUG o.g.t.i.provider.DefaultConnection - Tooling API provider 1.11 created. 09:48:01.099 [Connection worker] DEBUG o.g.t.i.provider.ProviderConnection - Configuring logging to level: INFO Tooling API is using target Gradle version: 1.11. Starting Gradle daemon

(Scott Palmer) #5

This is my new method:

void runSubGradle( String… tasks ) {

println “******* Calling Gradle Launcher ${} $project.projectDir - $tasks ************”

ProjectConnection connection = GradleConnector.newConnector()



try {

BuildLauncher build = connection.newBuild();



} finally {




(Pablo Munoz) #6

I believe you are getting this error as a result of configuring a GradleBuild task, which breaks for me with the same error going from 1.10 to 1.11

Here is the related changeset I found

I reported this on a separate thread also.

(Luke Daley) #7

You need to configure the connector to use the same Gradle environment…


(Luke Daley) #8

Raised as GRADLE-3052. Working on a fix for 1.12.