version 0.8.15 causes extractIncludeProto to fail in Gradle 7 #550
Comments
|
Here's the output when running the task with |
|
Any updates? |
|
Same issue here. For me it happens if I exclude any task which populates the build directory. |
|
8df229f was released today in v0.8.19 |
|
@ejona86 That's true, appreciated, but it still has the issue this topic concerns, that if you exclude tasks that Gradle knows populates the build directory while running extractIncludeProto, then the task fails. I can't really upgrade until it is resolved, as some of the developers at my work do that sort of thing (i.e. exclude certain tasks) regularly. |
|
Not that I have any time to look at this, but I'll note it isn't all that actionable as the plugin isn't in the stacktrace and there's no reproduction. |
|
Fair point re no reproduction. Here is a (fairly, probably the scala plugin is superfluous) minimal reproduction Thrillpool/gradle-protobuf-bug@720c56c Run I will make a fix over the weekend. I'll admit I didn't appreciate before making this reproduction that the java-library plugin was required to make the error happen, that is interesting, but I don't think it is a bug with that plugin. |
|
That's a pretty compact reproduction. Looks like it is happening before the task runs. I suspected something strange like that might be happening, but it isn't obvious how to resolve the issue if the other task will never be run. |
|
I have a fix, the troublesome line is this one bf6301a#diff-ce7f3a5cefd661ce9628d8d55b9ed9a02ff244a8a10dbcfd012818bad47a6e5eR150 inputFiles.getElements().map ... is the 'mapped provider' that Gradle is complaining about. Is there anything I should know regarding the tests for this project? When I clone the repo as is and run the tests I get 30 pass, 50 fail. The errors themselves are along the lines of 'Caused by: org.gradle.api.GradleException: protoc: stdout: . stderr: test1.proto: File not found.' I am on Windows, if it is significant. I'm sure I can work it out myself so if it's not something known don't worry. |
|
I will check this issue on sunday. |
|
@Thrillpool, I've not seen failures like that. I honestly don't know if the tests have recently been run on Windows, so that may indeed be the problem. |
|
@Thrillpool
@Toldry If you are unable to provide a scan: What is actually going on inside:
So I guess it's a slightly different issue. |
|
Neither of those workarounds sound especially practical for me.
To me it seems like either #452 should be reverted, given that it's just an optimisation anyway. Or bf6301a#diff-ce7f3a5cefd661ce9628d8d55b9ed9a02ff244a8a10dbcfd012818bad47a6e5eR150 line should be resolved. To me it seemed like it could be fixed just by restructuring the logic a bit. It wants to do this map of the provider and do a objectFactory.fileCollection().from on the mapped thing. But could we not just eagerly get inputFiles.getElements(), and just do some logic on the resulting Set and objectFactory.fileCollection().from the Set we make. |
|
I'll try to find the best solution for the issue this week. |
When using provider.map, Gradle has checks that can fail if the provider is used too early. For example: > Querying the mapped value of provider(interface java.util.Set) before > task ':p1:compileScala' has completed is not supported However, it seems those checks can also fire even if the incomplete task is properly registered dependency and only when accessed from an action. This is possible when using -x to exclude a task. This deserves a Gradle bug, but let's workaround it in the meantime. Fixes google#550
When using provider.map, Gradle has checks that can fail if the provider is used too early. For example: > Querying the mapped value of provider(interface java.util.Set) before > task ':p1:compileScala' has completed is not supported However, it seems those checks can also fire even if the incomplete task is a properly registered dependency and only when accessed from an action. This is possible when using -x to exclude a task. This deserves a Gradle bug, but let's workaround it in the meantime. Fixes google#550
|
It looks like protobuf plugin attempts to scan compile classpath and find .proto files there. Is there a real need to scan compile classpath? What if users who want .proto from jars would add the deps to a special protobuf configuration? Then compileClasspath scanning won't be needed, and exclusion of compileScala won't break proto tasks |
|
There is no real need. It is necessary to change the logic of work from dependencies. Stop taking dependencies from implementation, take them only from protobuf. |
|
Details about "don't depend on compilation tasks" here #578. |
When using provider.map, Gradle has checks that can fail if the provider is used too early. For example: > Querying the mapped value of provider(interface java.util.Set) before > task ':p1:compileScala' has completed is not supported However, it seems those checks can also fire even if the incomplete task is a properly registered dependency and only when accessed from an action. This is possible when using -x to exclude a task. This deserves a Gradle bug, but let's workaround it in the meantime. Fixes #550
After upgrading our project to Gradle 7 and upgrading the plugin to 0.8.15 , running
./gradlew extractIncludeProtocauses the following error:Notes
The text was updated successfully, but these errors were encountered: