Failed to determine the latest version for the following dependencies (use --info for details): #816
Comments
|
Can you try adding The module metadata stuff is very confusing and brittle. I’m really surprised it works at all since using the Gradle apis since 1.0 runs into these weird cases now. |
|
ah sorry forgot it, now applied in the latest commit: https://github.com/tek/splain/actions/runs/6450315854 But it doesn't change the outcome :-< |
|
It may be exclusive to Scala+gradle users, a minority to my impression |
|
Another workaround might be to disable Gradle module metadata from the source repository, so that it relies upon on the pom metadata like before. The modules are really only used by android and kotlin craziness so it’s usually safe to get rid of. |
|
Thanks for addressing it but I believe they are used by some other Gradle plugins to verify JVM binary compabilities. They will be disrupted if source repo ignored all of them. Instead, a fallback mechanism in your plugin should be a more preferable option |
|
The plugin is just calling the Gradle apis to resolve dependencies in a configuration. The problem is Gradle and the ecosystem have become incredibly complex so using these published apis is less likely to work, especially when other plugins abuse Gradle. It takes a lot of debugging to figure out what went wrong, whose is at fault, and who will actually fix it. Sometimes the Gradle team kindly steps in to sort it out. I think we’d need to isolate the version it broke at to see the code change that caused this and why. Then try to find a fix compatible with the intent and your project. |
|
FYI: the problem can be reproduced with any plugin v0.45 +, for v0.44 it behaved normally |
|
yep, just isolated it to this change (#721), kindly contributed by @jvandort from Gradle, Inc. The change looks very small and benign. We might need Justin's expertise, but I'll see if I can narrow it down further. I'm iterating by using |
|
The In your project this configuration does not need to be checked for dependency updates so skipping it worked. Without an expert to better explain the root cause, I think this is a pragmatic workaround. import com.github.benmanes.gradle.versions.updates.DependencyUpdatesTask
import org.gradle.api.specs.Spec
tasks.named<DependencyUpdatesTask>("dependencyUpdates").configure {
filterConfigurations = Spec<Configuration> {
!it.name.startsWith("incrementalScalaAnalysis")
}
} |
|
thanks a lot! Will try in 2 days. Happy thanksgiving! |
|
Same happens for me in an android/kotlin project: I can not say when it started to occur, but it happened in 0.48.0 and remains in 0.49.0. It might be related to the shift from Gradle 8.3 to 8.4 |
|
@WebTiger89 This looks like gradle/gradle#26672 because the Android plugin brings in an old version of xerces, which is incompatible with Gradle 8.4. You can use the workaround of adding the override in your |
…hread: ben-manes/gradle-versions-plugin#816 upgrade a gradle plugin
|
@ben-manes the circumvention works properly, has been integrated into tek/splain#115 I'd suggest keeping it open until a more systematic solution has been found |
* add Vtype-def-position option, guarded by a test suite * add filterConfigurations to dependencyUpdates, as suggested in this thread: ben-manes/gradle-versions-plugin#816 upgrade a gradle plugin
|
This workaround doesn't help 🙁 For now only work solution is modifying UPD: |
|
EDIT: It really helps. Hello, we use Android gradle + latest version of this plugin + Gradle 8.5 (should have workaround for xerces - gradle/gradle#26672 is closed for Gradle milestone 8.4)... but it still happen: for almost any dependency. |
|
right, other plugins hit this issue. You can also add to your gradle.properties these flags. 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 |
Sorry for the delay here. This is caused because the What I see as the root issue is that this plugin attempts to resolve all configurations, even those that are meant to be resolved leniently. However, a solution here seems difficult, since there is no "this configuration is resolved leniently" flag on a configuration. That flag is only present on the view of a configuration. I don't see how this plugin would know to skip resolving these configurations. |
|
Can confirm this is fixed in AGP 8.3.0 released Feb 29th |
This can be reproduced at this version:
https://github.com/tek/splain/actions/runs/6450250076
running
gradlew dependencyUpdates --infogives:Wondering if part of the resolving algorithm is incompatible with Scala
The text was updated successfully, but these errors were encountered: