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
Failures and warnings with Gradle 6.8-milestone-1 #432
Comments
I do not see a 6.8 release candidate, so I used the nightly snapshot (6.8-20201018220038+0000). I didn't see any warnings in my local projects. You can use |
I'm using com.github.ben-manes.versions
|
The Lines 71 to 75 in 4ef6307
|
Shouldn't that be |
Gradle's descriptions are confusing so I'm not sure, tbh
|
I have a project using Gradle 6.6.1, versions plugin 0.31.0, and Spring Boot (plugin) 2.4.0-M3 (amongst many other plugins and dependencies). I started updating its dependencies, and somewhere in the middle noticed lots of dependencies missing, and instead seeing those Downgrading back to Gradle 6.6.1 doesn't fix it. Unfortunately I cannot share the source, but I'll try to see if I can get a minimal example working. |
Here's a minimal project and step-by-step guide to reproduce this issue: https://github.com/napstr/gradle-versions-rip |
Thanks @napstr. Unfortunately, I won't be able to look at this soon as my workend is already committed, so at best would be next week to try to help. As you figured out, the error via
You could try modifying that filtering code in |
A quick look and their configuration settings haven't changed between versions.
That makes sense since some of those configurations are Gradle's. I'm not sure what the M4 plugin is doing differently to make the configurations become incompatible. |
Thanks for the instructions to test local builds of the plugin! |
hah, I didn't mean to use that slang but was tired, and mistyped it like that 😆 I took a quick peek and the cause seems to be this Spring commit. It sets the base Java configurations to extend Spring's own. Presumably when the child configuration is resolved it has to resolve its parent's and causes the failure. When we ensure that the child's copy is set to allow resolution (code), that must not override the parent and you see these failures. I'm not super confident on how we should treat @wilkinsona is a lot sharper than I am and maybe can advise on how to improve our usage. |
That commit in Spring Boot is configuring Spring Boot's own build (all the code lives in |
@wilkinsona oh, I might simply be wrong in my investigation so far. I was just about to post this bit which may be wrong, Snuck in a little more time, and I don't think that I can solve this programmatically. Spring's |
I confirm, reverting spring boot plugin to I hope they fixes this soon. Is there anything that could be done on your plugin side? |
I think we need some details from @wilkinsona about the changes between releases, at which point we can being theorizing about where the fix should go and what that might be. At the moment I do not know. |
The change in behaviour in Boot's plugin is due to this commit. The TL;DR of those changes is that we register an |
I imagine that the behaviour could be worked around by checking that the configuration is actually resolved before processing it: getProject().getConfigurations().all((configuration) -> {
ResolvableDependencies incoming = configuration.getIncoming();
incoming.afterResolve((resolvableDependencies) -> {
if (configuration.getState() == State.RESOLVED) {
this.resolvedDependencies.processConfiguration(configuration);
}
});
}); I'm reluctant to make that change right now as the state check looks unnecessary. It would be at risk of being removed in the future by someone tidying things up. To avoid that, we'd need to add a test that reproduces the problem but I can't do that without understanding exactly what's causing the problem. |
I guess it's the copying of the configuration that's causing the problem. I have a vague recollection that this has caused problems in the past. Assuming that after resolve callbacks are included in the copy, the callback above will be getting called when the made-resolvable copy is resolved but is then, presumably, triggering processing of the original unresolvable configuration. |
Thanks @wilkinsona. It does sound like our using |
I've opened spring-projects/spring-boot#24072. |
@ben-manes The issue is gone after upgrading to the fresh released Spring Boot 2.4.0. |
Thank you for the update @juergenzimmermann. And thank you @wilkinsona for being so helpful and fixing this promptly. |
When using Gradle 6.8-milestone-1 I get the following warnings for
gradle dependencyUpdates
:The text was updated successfully, but these errors were encountered: