Gradle 8.4 support? #814
Comments
|
Can you try adding |
|
This fix the second issue for detekt. But the main issue that prevent nearly everything to be found is still present. |
|
I use 8.4 in caffeine, but that is a Java project with a gradle.kts build. Unfortunately all of the magic that Kotlin and Gradle do around the module metadata makes it very brittle and tends to break the Gradle apis if some hidden, completely wrong kotlin hack is not emulated. If you think it is a Gradle bug please open it on their side. We mostly just script their APIs to generate a report since Gradle 1.0. |
|
rereading and yes this would be a Gradle or dependency issue. Sorry, I was focused on the second stacktrace and not the SAX issue. I believe that property is to control XML Schema validation, but why it is unrecognized or failing is beyond me. It seems like something to discuss with the Gradle folks. |
|
dang it, I started getting this SAX error as well in Caffeine. I'll need to dig in, maybe I was premature in thinking 8.4 worked fine (was on an rc). From the upgrade notes they mention scricter XML parsing, but I am unsure why it would break this plugin given it is their resolution logic failing. They recommend adding this to your gradle.properties: |
|
From what I can tell, it fails because xerces does not support this property?
This plugin is using |
|
Okay, I have a proof-of-concept version working that removes xerces, which then resolves this problem. It uses the |
|
Released in v49 |
|
Hum I'm still getting the Do I need to clear some caches or something? Tested with and without |
|
You’ll need to see if anything else in your buildEnvironment brings in an old xml library. I had to exclude xerces from the coveralls plugin (kt3k/coveralls-gradle-plugin#115) to resolve it in Caffeine. There doesn’t seem to be a workaround except getting it off your classpath. |
|
Well seems Android Gradle plugin does bring a few XML libs including xerces. And I can't figure out how to exclude them without issues. |
|
You’ll have to let them know. It’s kind of a sleeper as to when or if it explodes, so they might not realize there is an issue until you raise it. |
|
Reporting in AGP part of the tracker is useless unless you know who to ping :( And for that part I only know Tor to ping on lint issues. I guess others with contact will report it at some point internally. |
|
What about forcing it back to the jdk’s? I believe it gets the old xerces from a service loader and you can set a system property to explicitly chose the jdk one. |
|
This breaks the rest :( That's no big deal I can revert to 8.3 when checking deps, just won't be automated until it's fixed. Thanks for the help and fix on your side that's already a big step forward. |
Maybe just create and link the issue here so that people who stumble across this issue here can upvote. :) |
|
A stackoverflow answer recommended this instead, which makes a bit more sense to me, -Djavax.xml.parsers.SAXParserFactory=com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl
-Djavax.xml.transform.TransformerFactory=com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl
-Djavax.xml.parsers.DocumentBuilderFactory=com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImplWhen I try reverting to Caffeine's prior commit which had this problem, it fails without and succeeds with it when running 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.DocumentBuilderFactoryImplThis of course assumes you are using openjdk-based jvm (most common) and I verified on 11 / 17 / 21. Less popular alternatives like IBM's have their own flags. Does that work for you? |
|
Oh, an it turns out this plugin was never incompatible because it used xstreams (not xerces), which came from other plugins in our respective projects. This was still a good change to make since xstreams is known as a security risk and documents the workaround for other confused users (like myself!). But amusingly enough the plugin itself was always compatible. |
|
Can confirm the workaround works for my Android projects thanks. |
Can't seem to find any tracking issue for this, so I've filed a bug in Google's IssueTracker regarding this issue, feel free to star/upvote it :) |
After updating to Gradle 8.4
gradlew dependencyUpdatesno more detect most versions.I see 2 kind of errors:
The biggest one that seems to be a Gradle bug, but maybe not.
And another one.
The text was updated successfully, but these errors were encountered: