Gradle 4.3 RC1 is available for testing; see the release notes.
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
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.
@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?
@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.
Done.
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…
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}}"
}
}
@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.
It appears the new validation introduced by Validate all properties not just the annotated ones · gradle/gradle@22b9d7b · GitHub surfaced some errors in our plugin. This bug report contains a stack track of what happens: Doesnt work with Gradle 4.3 RC1 · Issue #170 · google/protobuf-gradle-plugin · GitHub . 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.
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.
btw, RC-2 also produces the error.
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.
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?
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.