-
Notifications
You must be signed in to change notification settings - Fork 4
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
InvalidUserDataException from Gradle after applying this plugin #13
Comments
This may be related to the changes I recently made. I should be able to poke around by Monday. |
#14 seems to take care of this by undoing that part of the last change (which apparently wasn't needed but seemed to be at the time 🤷♂️). The specific line that seems troublesome is the realization of the dependency list here: https://github.com/kelloggm/multi-version-control/blob/use-gradle-plugin/build.gradle#L86 for which a reproducing test was added. |
@mwhipple Do you believe this is related? It will fix this problem? If so, I can make a quick release. |
This should fix the problem, yes (it was locally reproduced and resolved). I remember dealing with these types of Gradle problems a long time ago but don't remember much practical info beyond them being a hassle (and at the time hoping Gradle v2 would save us all from them), but I think I can describe the problem in a nutshell. Configs can't be modified after being resolved in a way that would cause those previous resolutions to become stale. Ideally this could be managed by performing actions in the proper stage so any such modifications are done in the configuration stage and resolutions in the execution stage, but in cases like the above where resolutions are done during the configuration stage the ordering needs to be controlled within that stage. I'd think the best solution would also involve replacing any config phase resolutions (like that List coercion) with lazy analogs, but moving this plugin's config modifications back to as soon as possible rather than the end of config hook at least shrinks the exposed area and should avoid that type of issue when generally dealing with user configured tasks (I think a poorly behaved plugin or any custom config prior to applying the plugin could still lead to the same type of issue). |
Hi!
I'm one of the maintainers of the Checker Framework. I started working on a gradle plugin myself a few weeks ago, but just discovered that you've already written one (awesome!). I tried out your plugin on a sample project and haven't been able to get it to work. I've tried to apply the Nullness Checker and Regex Checker, and I'm getting this error from Gradle: "cannot change dependencies of configuration ':compile' after it has been included in dependency resolution." I'll include the full stacktrace below, along with my gradle version. You can find the actual project I was testing on here: https://github.com/kelloggm/multi-version-control/tree/use-gradle-plugin
More generally, I'd love to collaborate to make this plugin an officially supported part of the Checker Framework - our gradle support (i.e. the document at https://raw.githubusercontent.com/typetools/checker-framework/master/docs/manual/checkerframework.gradle) has been pretty lousy, and we'd like to improve it.
Here's the stacktrace of the failure:
The text was updated successfully, but these errors were encountered: