Gradle 4.3 RC1 is available for testing


(Eric Wendelin) #1

Gradle 4.3 RC1 is available for testing; see the release notes.


(Eric Wendelin) #2

(Jörn Huxhorn) #3

I get the following exception with Gradle 4.3-rc-1 and spring-boot 1.5.4.RELEASE:

org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':foo:bootRepackage'.
        at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:50)
        at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:97)
        at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:87)
        at org.gradle.api.internal.tasks.execution.ResolveTaskArtifactStateTaskExecuter.execute(ResolveTaskArtifactStateTaskExecuter.java:52)
        at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:52)
        at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:54)
        at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
        at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:34)
        at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker$1.run(DefaultTaskGraphExecuter.java:248)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110)
        at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:241)
        at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:230)
        at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.processTask(DefaultTaskPlanExecutor.java:123)
        at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.access$200(DefaultTaskPlanExecutor.java:79)
        at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:104)
        at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:98)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.execute(DefaultTaskExecutionPlan.java:626)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.executeWithTask(DefaultTaskExecutionPlan.java:581)
        at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.run(DefaultTaskPlanExecutor.java:98)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
        at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
Caused by: org.gradle.internal.typeconversion.UnsupportedNotationException: Cannot convert the provided notation to a File or URI: task ':foo:jar'.
The following types/formats are supported:
  - A String or CharSequence path, for example 'src/main/java' or '/usr/include'.
  - A String or CharSequence URI, for example 'file:/usr/include'.
  - A File instance.
  - A Path instance.
  - A Directory instance.
  - A RegularFile instance.
  - A URI or URL instance.
        at org.gradle.internal.typeconversion.ErrorHandlingNotationParser.parseNotation(ErrorHandlingNotationParser.java:56)
        at org.gradle.api.internal.file.AbstractFileResolver.convertObjectToFile(AbstractFileResolver.java:126)
        at org.gradle.api.internal.file.AbstractBaseDirFileResolver.doResolve(AbstractBaseDirFileResolver.java:69)
        at org.gradle.api.internal.file.AbstractFileResolver.resolve(AbstractFileResolver.java:86)
        at org.gradle.api.internal.file.AbstractFileResolver.resolve(AbstractFileResolver.java:68)
        at org.gradle.api.internal.tasks.DefaultTaskInputs.toFile(DefaultTaskInputs.java:367)
        at org.gradle.api.internal.tasks.DefaultTaskInputs.access$100(DefaultTaskInputs.java:46)
        at org.gradle.api.internal.tasks.DefaultTaskInputs$6.validate(DefaultTaskInputs.java:345)
        at org.gradle.api.internal.tasks.StaticValue.validate(StaticValue.java:43)
        at org.gradle.api.internal.tasks.DefaultTaskInputFilePropertySpec.validate(DefaultTaskInputFilePropertySpec.java:124)
        at org.gradle.api.internal.tasks.DefaultTaskInputs.validate(DefaultTaskInputs.java:161)
        at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:47)
        ... 24 more

(Jochen Berger) #4

I have a task that has a property outputFormatter that can take a Closure<Result>. When I run the task with 4.3-rc-1, I get

...
Caused by: java.lang.NullPointerException: Cannot get property 'outdated' on null object
        at init_ee2krdz9v7kavbv5i3saf2frz$_run_closure1$_closure3.doCall(/home/jochen/.gradle/init.gradle:9)
        at org.gradle.util.GUtil.uncheckedCall(GUtil.java:436)
        at org.gradle.util.DeferredUtil.unpack(DeferredUtil.java:37)
        at org.gradle.api.internal.project.taskfactory.TaskPropertyInfo$3.validate(TaskPropertyInfo.java:105)
        at org.gradle.api.internal.tasks.TaskPropertyValue.validate(TaskPropertyValue.java:38)
        at org.gradle.api.internal.tasks.DefaultTaskInputPropertySpec.validate(DefaultTaskInputPropertySpec.java:53)
        at org.gradle.api.internal.tasks.DefaultTaskInputs.validate(DefaultTaskInputs.java:158)
        at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:47)

outdated is a property of the Result object. This does not happen with earlier versions.


(Benjamin Muschko) #5

@huxi Thanks for reporting this issue. It might be that the Spring Boot plugin version has become incompatible with 4.3-rc1. Could you please provide a sample project that reproduces the issue? I think it would also be helpful if you’d open an issue with the Spring Boot project. Did the project still work with 4.2?


(Benjamin Muschko) #6

@jochenberger Thanks for reporting this issue. Could you open an issue and provide some sample project that reproduces the issue? At the moment I am not clear with Result type you are using here.


(Jörn Huxhorn) #7

Done.


(Jörn Huxhorn) #8

Filing an issue with spring-boot would be futile since their official stance is that “Gradle 4 isn’t officially supported with Boot 1.5.” (i.e. their latest release version).

The related issues (links are provided in the Github issue I just created) have been around for more than 3 years and we have to live with 20-30s of Gradle configuration time in our main build because of this.

Quite frustrating…


(Jochen Berger) #9

For the record: This is a minimal version that reproduces the issue for me:

plugins {
  id 'com.github.ben-manes.versions' version '0.15.0'
}

apply plugin: 'java'

repositories {
  jcenter()
}

dependencies {
  compile 'org.slf4j:slf4j-api:1.7.25'
}

dependencyUpdates {
  outputFormatter = { result->
    println "Outdated dependencies: ${result.outdated.dependencies.collect {it.name}}"
  }
}

cc @Benjamin_Manes


(Benjamin Muschko) #10

@jochenberger Thanks, I can reproduce the issue. It’s unclear to me why you assign a closure to the property with a parameter called “result”. The documentation of the plugin does not mention the type of the parameter. In your provided example “result” is null.

Could you please open an issue against the plugin? I’d like the plugin author to comment on that behavior. If you or the plugin author happen to identify an issue in Gradle then please open an issue here: https://github.com/gradle/gradle/issues.


(Spencer Fang) #11

It appears the new validation introduced by https://github.com/gradle/gradle/commit/22b9d7b surfaced some errors in our plugin. This bug report contains a stack track of what happens: https://github.com/google/protobuf-gradle-plugin/issues/170 . It looks like only files and directories can be used as inputs going forward.

Today, we pass a subclass of DefaultSourceDirectorySet to the TaskInput:


I’ve tried to change it to add each proto file from the sourceset, rather than passing in the sourceset:

sourceSet.proto.files.each {
    Utils.addFilesToTaskInputs(project, inputs, it)
}

But the result is that the copied file goes to the top level directory and the directory structure is lost. For example, this file would be incorrectly be placed here

build/tests/testProject/build/extracted-include-protos/test/messages.proto

Rather than here:

build/tests/testProject/build/extracted-include-protos/test/io/grpc/testing/integration/messages.proto

I am having some trouble finding resources about the correct way to do this. Is it wrong to pass runtime objects across task boundaries? By the way, I am trying to get a working version of the code in Gradle 4.0 that avoids passing around source sets to the TaskInput before I try it again with Gradle 4.3-rc-1, so the above snippet reflects 4.0.


(Jochen Berger) #12

The resultparameter is a plugin-specific type and is passed to the closure by the plugin.
I don’t think that it is an issue with the plugin given it worked with earlier Gradle versions.


(Lóránt Pintér) #13

(Jochen Berger) #14

btw, RC-2 also produces the error.


(Benjamin Muschko) #15

I created an issue with the plugin: https://github.com/ben-manes/gradle-versions-plugin/issues/185 and am awaiting some feedback from the plugin author.


(Lóránt Pintér) #16

You can use inputs.files() instead of inputs.file(). The just released Gradle 4.3-rc-2 should not break the build even if you don’t, and instead produce a warning like this:

Using TaskInputs.file() with something that doesn’t resolve to a File object has been deprecated and is scheduled to be removed in Gradle 5.0. Use TaskInputs.files() instead.

Can you please check if it works as you’d expect with Gradle 4.3-rc-2?


(Spencer Fang) #17

Thank you for your help. I can confirm that with 4.3-rc-2 the build succeeds with a warning if I make no changes, and if I switch to using TaskInput.files I do not get a warning.