-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gradle plugin not compatible with Gradle configuration cache #1527
Comments
Thanks for the report and the hints at how to investigate the issue. Ill tackle this with priority |
Thank you @l-1squared. If you have any questions, let me know. I can also review a PR. |
Hi, So, the gradle documentation suggests that you use properties and providers for "everything", which prompted me to alter the JGivenTaskExtension in the following way:
Unfortunately, upon testing, this produces an I tried to debugv this and the error seems to happen, because we create the extensions in JGivenPlugin.java:38 on a Task, and not on the Project. Thing is, that I want to create them on the task, which puts me at an impasse, because I don't know how to supply an object factory to my extension. |
That sounds like you are on the right track. The error is unexpected though. Maybe it's just some detail that is not right. It's unfortunately often too easy to get something wrong with these APIs. If you could push what you have to a branch, I am happy to take a look. |
Ah, I finally happened upon this: gradle/gradle#16936. I'll try it |
hmm, maybe not. But it gave me an idea: I could create the extension via the object factory and then simply add to the task. (Did so in my WIP commit) I might be on to something... |
Okay it looks like you are right. Unfortunately task extensions do not seem to be handled that easily as "normal" (project) extensions. But the workaround suggested in gradle/gradle#16936 (comment) looks slightly wrong. That syntax does not work for me. I adjusted everything I would in this commit: Feel free to pick parts you need from there. Unfortunately, now the configuration cache is still failing with issues with the |
Thanks for the refactoring which helped me out a great deal. Aside from the issue you already mentioned, I also removed a null checked which seemed to be important. Hope I'll get both sorted out quickly |
these have been detailed https://github.com/jjohannes/JGiven/commit/cc3f67a7b4b39f9f78599c2cea18c42c95870c73 and authority to use these has been explicitly granted #1527 (comment) Signed-off-by: l-1squared <30831153+l-1squared@users.noreply.github.com>
Unfortunately, this will still take a while. Also there is another test failure about the test task running, when it shouldn't that I don't understand yet. |
I am not sure if extending the (internal) ReportContainer implementation is the issue here. I also don't know about an alternative solution. Implementing all "DomainObjectContainer" methods yourself can't be it. It feels to me like public API is missing and what you are doing is OK. I have looked at this again and TBH I don't understand the error. I can't finde the reference in the code the error is complaining about. For reference, this is the trace from the CC report: I'll see if I can get someone from Gradle to have a look. |
Good news @l-1squared. @mlopatkin helped me to track down the problem. It is totally unrelated to the "internal" container implementation. You do not need to change anything there. This is the fix: 37c736e |
these have been detailed https://github.com/jjohannes/JGiven/commit/cc3f67a7b4b39f9f78599c2cea18c42c95870c73 and authority to use these has been explicitly granted #1527 (comment) Signed-off-by: l-1squared <30831153+l-1squared@users.noreply.github.com>
The Configuration Cache feature of Gradle requires a strict separation between configuration time and execution time state.
The JGiven Gradle plugin is violating this right now by postponing the access to some configuration state to execution time by using Java
Callable
s in JGivenPlugin to delay access to certain configuration values. For this kind of "lazy access" Gradle's Properties and Providers would be the better solution.To reproduce the problem, run
gradle jgivenTestReport --configuraion-cache
on a Gradle project that applies thecom.tngtech.jgiven.gradle-plugin
plugin.Trace from the configuration cache problem report:
The text was updated successfully, but these errors were encountered: