Dependency task can fail to BootJar and BootWar afterResolve hooks #30586
Comments
spring-projects-issues
added
the
status: waiting-for-triage
|
Thanks, @DanielThomas. I'm a little surprised by Gradle's behaviour here. We're only dealing with resolved configurations and those that have resolved without errors. I was not aware that working with the configuration's resolved artifacts could trigger further resolution that could then cause an error to occur. I'll see what we can do to work around this behaviour. |
|
Yeah, the contract is that you can expect the file to exist, so You can probably just capture the resolution result and walk the resolved artifacts later (but remember resolved != artifacts have been downloaded, so you'll want to watch for that and avoid it if you can, or trigger downloads for the whole configuration). Gradle 7.5 will add new APIs for parallel artifact queries and IIRC they were also adding support for resolution results to be serializable, so I don't think capturing the resolution result is a problem for configuration caching later. |
|
Unfortunately, it was adding configuration cache support that got us into this situation. We support it with earlier versions of Gradle so we can’t store the resolution result. It looks like we should at least be able to make the current approach more robust though. |
wilkinsona
added
type: bug
because 1.30 is missing the 'android' classifier See related issues: - https://bitbucket.org/snakeyaml/snakeyaml/issues/519/release-130-is-missing-android-classifier - spring-projects/spring-boot#30586 - gradle/gradle#20417
|
@DanielThomas Thanks again for reporting this and the initial analysis. I've pushed some changes that should make things more robust. Unfortunately, resolving the artifacts' files is unavoidable at the moment. I've added a call to |
wilkinsona
changed the title
|
Thanks @wilkinsona. Should I create a separate issue to address this properly w/ Gradle 7.5? Resolution results will be available as task inputs from that release. (We have many workflows where we want to resolve metadata only, not files, and this slows them down, but the parallel resolution is a nice improvement). |
|
I've opened #31216. |
To reproduce:
javafakerwhich depends on thesnakeyaml:androidclassifier which has since been removed, and cause an upgrade tosnakeyaml:Two problems I see with this
afterResolvehook:dependenciesanddependencyInsighttasks to break up making it difficult to troubleshoot the problem without removing the plugins. Those use lenient configurations to allow the configuration to resolve successfully. That's true for any resolution failure incidentally, not only this one, this just happens to be the case we ran intoResolvedArtifact.getFile()eagerly resolves the artifact so you wind up always resolving artifact files even if you only wanted metadata. Other than it being important that resolving a configuration does not resolve artifact files, this also resolves artifacts serially. If you do this elsewhere, you want to callgetFiles()on the configuration first before walking the artifacts to give Gradle the opportunity to do the resolution in parallelGradle underlying behaviour needs some improvement here too, a call to
configuration.getFiles()fails even without Spring Boot's plugin applied, and it's impossible to tell which library requested the classifier without checking all the module metadata or connecting a debugger. I created gradle/gradle#20417 for that.Full stack trace for a
dependenciestask failure:The text was updated successfully, but these errors were encountered: