Libraries not resolving on Gradle 8.4

[hvisser]

From @extmkv:

See this repository with the issue: https://github.com/extmkv/versions-bump

I notice that works if I've the libs.versions.toml on the gradle folder + with the other toml's on the config/libs folder.
When I also moved the libs.versions.toml to config/libs/libs.toml it started to happen

Originally posted by @extmkv in #125 (comment)

[hvisser]

@extmkv re: your question about repositories; it should pick up your project and plugin repositories and at first glance those are configured correctly, but I'll check out your project in more detail.

Update: OK this is weird, but a good test case I suppose :) From the logs it looks like all is well, but Gradle reports that the dependencies like material cannot be resolved. As a test I added the same dependency to another project and all of a sudden none of the dependencies in the Google repository are resolving 🙃 🤔

[hvisser]

This seems to be related to the Gradle version. With 8.3 everything works just fine, with 8.5 resolving fails.

[hvisser]

Root cause seems to be this change. Adding the suggested workaround to gradle.properties fixes the issue for me, but makes me wonder what is pulling in an old parser somewhere (one of the plugin dependencies?)

https://docs.gradle.org/current/userguide/upgrading_version_8.html#xml_parsing_now_requires_recent_parsers

@extmkv would be great if you can check if adding

systemProp.javax.xml.parsers.SAXParserFactory=com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl
systemProp.javax.xml.transform.TransformerFactory=com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl
systemProp.javax.xml.parsers.DocumentBuilderFactory=com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl

fixes the issue for you, just to be sure we're looking at the same thing. To be sure, please run Gradle with the --refresh-dependencies flag.

[hvisser]

A wrong/old parser affects internal Gradle dependency parsing. The maven-metadata.xml file cannot be parsed in that case, resulting in the unresolved messages. For Android projects this is probably common, because until recently the Android Gradle plugin would pull in an incompatible version of xerces.

This also happens with versions plugin, so #140 fails the build if this situation is detected.

cc @ben-manes

[ben-manes]

yeah, it took me some digging to figure that out and then get the Gradle team to document that workaround (gradle/gradle#26672). I think the Gradle team reacted too quickly as it does not provide the user a meaningful error message, e.g. that the dependency graph is corrupted. A check in the plugin is a nice idea.

[extmkv]

@hvisser thanks a lot for the quick debug and reply!

I added the configurations and ran the task, and all dependencies, including those from private repositories, got updated <3

[hvisser]

yeah, it took me some digging to figure that out and then get the Gradle team to document that workaround (gradle/gradle#26672). I think the Gradle team reacted too quickly as it does not provide the user a meaningful error message, e.g. that the dependency graph is corrupted. A check in the plugin is a nice idea.

@ben-manes Yeah breaking dependency resolution by including an XML parser and basically swallowing the error is eh... interesting. But since you filed the issue there's at least a page I can link to now 😎