Closed tribbloid closed 6 months ago
ben-manes
commented
12 months ago Can you try adding apply plugin: 'jvm-ecosystem' (https://github.com/ben-manes/gradle-versions-plugin/issues/746) and see if that helps?
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.
tribbloid
commented
12 months ago 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 :-<
tribbloid
commented
12 months ago It may be exclusive to Scala+gradle users, a minority to my impression
ben-manes
commented
12 months ago 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.
tribbloid
commented
12 months ago 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
ben-manes
commented
12 months ago 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.
tribbloid
commented
12 months ago FYI: the problem can be reproduced with any plugin v0.45 +, for v0.44 it behaved normally
ben-manes
commented
12 months ago yep, just isolated it to this change (https://github.com/ben-manes/gradle-versions-plugin/pull/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 publishToMavenLocal for a snapshot version to use with your repository.
ben-manes
commented
12 months ago The incrementalScalaAnalysis configurations set the usage and category capability attributes, which then causes their dependencies to not resolve against that variant. I tried the workarounds discussed in https://github.com/gradle/gradle/issues/6750 and https://github.com/gradle/gradle/issues/6854, but could not get it to work.
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!
WebTiger89
commented
11 months ago Same happens for me in an android/kotlin project:
The following dependencies exceed the version found at the milestone revision level:
- org.jetbrains.kotlinx:kotlinx-coroutines-core-jvm [1.7.3 <- 1.5.0]
https://github.com/Kotlin/kotlinx.coroutines
Failed to determine the latest version for the following dependencies (use --info for details):
- androidx.activity:activity-compose
- androidx.compose.compiler:compiler
- androidx.compose.material:material-icons-extended
- androidx.compose.material3:material3
- androidx.compose.ui:ui-test-manifest
- androidx.compose.ui:ui-tooling
- androidx.compose.ui:ui-tooling-preview
- androidx.compose.ui:ui-util
- androidx.core:core-ktx
- androidx.datastore:datastore
- com.google.accompanist:accompanist-permissions
- com.google.protobuf:com.google.protobuf.gradle.plugin
- com.google.protobuf:protobuf-javalite
- com.google.protobuf:protoc
- com.pinterest:ktlint
- com.squareup.okhttp3:okhttp
- com.squareup.okio:okio
- com.valentinilk.shimmer:compose-shimmer
- io.gitlab.arturbosch.detekt:detekt-cli
- io.kotest:kotest-runner-junit5
- io.mockk:mockk
- org.cqfn.diktat:diktat-rules
- org.jetbrains.kotlinx:kotlinx-benchmark-runtime
- org.jetbrains.kotlinx:kotlinx-coroutines-android
- org.jetbrains.kotlinx.benchmark:org.jetbrains.kotlinx.benchmark.gradle.plugin
- org.json:json
- org.lighthousegames:logging-android
- org.openjdk.jmh:jmh-core
Gradle release-candidate updates:
- Gradle: [8.4: UP-TO-DATE]
Generated report file D:\dev\android\workspace\dcapps\build\dependencyUpdates\report.txt
478 problems were found storing the configuration cache, 9 of which seem unique.
- Plugin 'com.android.internal.application': execution of task ':dependencyUpdates' caused invocation of 'Task.convention' in other task at execution time which is unsupported.
See https://docs.gradle.org/8.4/userguide/configuration_cache.html#config_cache:requirements:use_project_during_execution
- Plugin 'com.android.internal.application': execution of task ':dependencyUpdates' caused invocation of 'Task.project' in other task at execution time which is unsupported.
See https://docs.gradle.org/8.4/userguide/configuration_cache.html#config_cache:requirements:use_project_during_execution
- Plugin 'com.android.internal.library': execution of task ':dependencyUpdates' caused invocation of 'Task.project' in other task at execution time which is unsupported.
See https://docs.gradle.org/8.4/userguide/configuration_cache.html#config_cache:requirements:use_project_during_execution
- Plugin 'org.jetbrains.kotlin.jvm': execution of task ':dependencyUpdates' caused invocation of 'Task.project' in other task at execution time which is unsupported.
See https://docs.gradle.org/8.4/userguide/configuration_cache.html#config_cache:requirements:use_project_during_execution
- Plugin class 'org.gradle.api.plugins.JavaBasePlugin': execution of task ':dependencyUpdates' caused invocation of 'Task.project' in other task at execution time which is unsupported.
See https://docs.gradle.org/8.4/userguide/configuration_cache.html#config_cache:requirements:use_project_during_execution
- Task `:dependencyUpdates` of type `com.github.benmanes.gradle.versions.updates.DependencyUpdatesTask`: cannot serialize a lambda that captures or accepts a parameter of type 'org.gradle.api.artifacts.Configuration' as these are not supported with the configuration cache.
See https://docs.gradle.org/8.4/userguide/configuration_cache.html#config_cache:requirements:disallowed_types
- Task `:dependencyUpdates` of type `com.github.benmanes.gradle.versions.updates.DependencyUpdatesTask`: execution of task ':dependencyUpdates' caused invocation of 'Task.convention' in other task at execution time which is unsupported.
See https://docs.gradle.org/8.4/userguide/configuration_cache.html#config_cache:requirements:use_project_during_execution
- Task `:dependencyUpdates` of type `com.github.benmanes.gradle.versions.updates.DependencyUpdatesTask`: execution of task ':dependencyUpdates' caused invocation of 'Task.project' in other task at execution time which is unsupported.
See https://docs.gradle.org/8.4/userguide/configuration_cache.html#config_cache:requirements:use_project_during_execution
- Task `:dependencyUpdates` of type `com.github.benmanes.gradle.versions.updates.DependencyUpdatesTask`: invocation of 'Task.project' at execution time is unsupported.
See https://docs.gradle.org/8.4/userguide/configuration_cache.html#config_cache:requirements:use_project_during_execution
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
ben-manes
commented
11 months ago @WebTiger89 This looks like https://github.com/gradle/gradle/issues/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 gradle.properties.
tribbloid
commented
11 months ago @ben-manes the circumvention works properly, has been integrated into https://github.com/tek/splain/pull/115
I'd suggest keeping it open until a more systematic solution has been found
egorikftp
commented
10 months ago This workaround doesn't help 🙁 https://github.com/ben-manes/gradle-versions-plugin/issues/816#issuecomment-1752209101
For now only work solution is modifying gradle.properties https://github.com/gradle/gradle/issues/26672
UPD: For anyone who uses plugin in Android projects, everything should be fixed in AGP 8.3 https://issuetracker.google.com/issues/306301014
mtrakal
commented
9 months ago EDIT: my fault, I didn't read the previous comment with the mentioned AGP 8.3.*
It really helps. build-tools = "8.3.0-alpha17"
Hello, we use Android gradle + latest version of this plugin + Gradle 8.5 (should have workaround for xerces - https://github.com/gradle/gradle/issues/26672 is closed for Gradle milestone 8.4)... but it still happen:
Caused by: org.gradle.internal.UncheckedException: org.xml.sax.SAXNotRecognizedException: Property 'http://javax.xml.XMLConstants/property/accessExternalSchema' is not recognized.
at org.gradle.internal.UncheckedException.throwAsUncheckedException(UncheckedException.java:68)
at org.gradle.internal.UncheckedException.throwAsUncheckedException(UncheckedException.java:41)
at org.gradle.internal.ErroringAction.execute(ErroringAction.java:38)
at org.gradle.internal.resource.local.LocalFileStandInExternalResource.withContent(LocalFileStandInExternalResource.java:171)
at org.gradle.internal.resource.local.DefaultLocallyAvailableExternalResource.withContent(DefaultLocallyAvailableExternalResource.java:103)
at org.gradle.api.internal.artifacts.repositories.maven.MavenMetadataLoader.parseMavenMetadataInto(MavenMetadataLoader.java:74)
at org.gradle.api.internal.artifacts.repositories.maven.MavenMetadataLoader.parseMavenMetadataInfo(MavenMetadataLoader.java:69)
at org.gradle.api.internal.artifacts.repositories.maven.MavenMetadataLoader.load(MavenMetadataLoader.java:50)
... 187 more
Caused by: org.xml.sax.SAXNotRecognizedException: Property 'http://javax.xml.XMLConstants/property/accessExternalSchema' is not recognized.
at org.apache.xerces.parsers.AbstractSAXParser.getProperty(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.setProperty(Unknown Source)
at org.apache.ivy.util.XMLHelper.newSAXParser(XMLHelper.java:92)
at org.apache.ivy.util.XMLHelper.parse(XMLHelper.java:170)
at org.apache.ivy.util.XMLHelper.parse(XMLHelper.java:149)
at org.apache.ivy.util.XMLHelper.parse(XMLHelper.java:144)
at org.apache.ivy.util.XMLHelper.parse(XMLHelper.java:138)
at org.gradle.api.internal.artifacts.repositories.maven.MavenMetadataLoader$2.doExecute(MavenMetadataLoader.java:77)
at org.gradle.api.internal.artifacts.repositories.maven.MavenMetadataLoader$2.doExecute(MavenMetadataLoader.java:74)
at org.gradle.internal.ErroringAction.execute(ErroringAction.java:36)
... 192 morefor almost any dependency.
ben-manes
commented
9 months ago 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
jvandort
commented
9 months ago 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
publishToMavenLocalfor a snapshot version to use with your repository.
Sorry for the delay here.
This is caused because the incrementalScalaAnalysisFor* configurations are not meant to be resolved directly. In fact, we actually expect there to be failed dependencies here. Instead of being resolved directly, we use an artifactView with lenient=true here. This allows for dependencies to fail resolution without throwing an exception.
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.
elevenfive
commented
6 months ago 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