GradleExecutionHelper has become @ApiStatus.Internal, what's a replacement?

IntelliJ Platform
,
1

Hi!

My plugin uses GradleExecutionHelper to execute a few tasks. Now since 252 this class has become @ApiStatus.Internal.

The documentation says to use ExternalSystemUtil#runTask which is high level. But in my case I need to pass certain arguments to the Gradle connection, for instance --continuous, and pass it the correct Java home, per ExternalSystemApiUtil.getExecutionSettings.

Is there a public way to do that?

I could certainly just use the low level Gradle Tooling APIs but I can see that GradleExecutionHelper does quite a few clever things, like pooling connections, etc. which would be a shame to not benefit from.

Thanks a lot.

3

Hello @BoD, which function do you use in the GradleExecutionHelper?

The command line argument can be provided using the ExternalSystemTaskExecutionSettings#setScriptParameters function.

TaskExecutionUtil.runTask(
  TaskExecutionSpec.create()
    .withProject(project)
    .withSystemId(GradleConstants.SYSTEM_ID)
    .withSettings(ExternalSystemTaskExecutionSettings().also {
      it.externalSystemIdString = GradleConstants.SYSTEM_ID.id
      it.externalProjectPath = projectPath
      it.taskNames = listOf("myTask")
      it.scriptParamters = "--continuous"
    })
)

The main issue with GradleExecutionHelper is that it requires proper preconfiguration. For example, the GradleExecutionHelper#execute function doesn’t create an output tool window. It can be execute only on the background thread, with prepared Job (ProgressIndicator) in thread context. Also, the LongRunningOperation API is fragile. In the previsous Gradle vesions, the LongRunningOperation#addJvmArguments replaced all user defined JVM arguments instead of adding. The same issue for system properties and environment variables is present in the new Gradle versions.

1 Like
4

Thanks a lot for the insights, and the hint about TaskExecutionUtil.

I was using GradleExecutionHelper().execute that takes a connection lambda, on which I either call run() or model() and get().

In the end, I opted to use the Gradle Tooling API directly (GradleConnector.newConnector()). For my use case I need to handle the background thread manually so I think this is OK and seems to work fine.