Closed Siedlerchr closed 11 months ago
mikepenz
commented
11 months ago Thank you @Siedlerchr for the report.
Based on the stacktrace, it unfortunately looks like this is occurring internally within Gradle and not in code in our control. Do you have an example project, or can this be somehow reproduced with the sample project there? Perhaps that could lead to additional pointers.
Possibly also worth to try upgrading to Gradle 8.3 just in case
Siedlerchr
commented
11 months ago Hi, I searched a bit around and it could be an issue if there's some kind of cycle in the dependencied. But I am not sure https://github.com/gradle/gradle/issues/22850
Is there an option to exclude transitive deps in the plug in?
mikepenz
commented
11 months ago @Siedlerchr there is not. the plugin uses the gradle apis to query the dependencies. However it does not make a difference between top-level or transitive dependencies. As all have to be given credit for in the app.
The given code responsible for collecting: https://github.com/mikepenz/AboutLibraries/blob/develop/plugin-build/plugin/src/main/kotlin/com/mikepenz/aboutlibraries/plugin/util/DependencyCollector.kt#L73-L125
Siedlerchr
commented
11 months ago Hmm thanks already . Would it be possible to provide a debug version that prints out the current dependecxy that is processed? . I'm trying to figure out the last dependency that is processed before it crashes so that I can narrow it down. I could try that on Monday then again
mikepenz
commented
11 months ago Published a version of the plugin with extra logs as 10.9.1-debug01 (this version only exists for the plugin, not for the rest of the normal android dependencies)
Find the related commit here: https://github.com/mikepenz/AboutLibraries/commit/96f1e33a44120f60dd5a5c98123c897b6a10fa08
Siedlerchr
commented
11 months ago Thanks a lot, that is really helpful and also the exception handling. I think I found the culprit library now. Seems to be some issue with an internal library from our company.
[com.mikepenz.aboutlibraries.plugin.util.DependencyCollector] getResolvedArtifacts 4 :: allModuleArtifacts
=> It crashes in xxx.xxxx:xxx-xx:2.5-SNAPSHOT;runtimeElements
mikepenz
commented
11 months ago I suppose the catch(throwable) won't protect in that case though.
Not sure what other good options there could be 🤔
We do filter some build variants. it could be something to add a filter for some dependencies at collection level.
Siedlerchr
commented
11 months ago No, actually build completes, that is fine, that goes through now. The exception handling helps to catch that stack overflow error and continues with the next one.
Even with your plugin:
2023-09-25T13:09:47.331+0200 [DEBUG] [com.mikepenz.aboutlibraries.plugin.util.DependencyCollector] getResolvedArtifacts 1 :: com.mikepenz:aboutlibraries:10.9.0-b02
2023-09-25T13:09:47.331+0200 [DEBUG] [com.mikepenz.aboutlibraries.plugin.util.DependencyCollector] getResolvedArtifacts 4 :: allModuleArtifacts
2023-09-25T13:09:47.340+0200 [INFO] [com.mikepenz.aboutlibraries.plugin.util.DependencyCollector] Found ambiguous variant - com.mikepenz:aboutlibraries:10.9.0-b02;releaseVariantReleaseRuntimePublication
at org.gradle.api.internal.artifacts.PreResolvedResolvableArtifact.hashCode(PreResolvedResolvableArtifact.java:61)
at org.gradle.api.internal.artifacts.DefaultResolvedDependency$ResolvedArtifactComparator.compare(DefaultResolvedDependency.java:225)
at org.gradle.api.internal.artifacts.DefaultResolvedDependency$ResolvedArtifactComparator.compare(DefaultResolvedDependency.java:205)
at java.base/java.util.TreeMap.compare(TreeMap.java:1570)
at java.base/java.util.TreeMap.addEntryToEmptyMap(TreeMap.java:776)
at java.base/java.util.TreeMap.put(TreeMap.java:785)
at java.base/java.util.TreeMap.put(TreeMap.java:534)
at java.base/java.util.TreeSet.add(TreeSet.java:255)
at org.gradle.api.internal.artifacts.ivyservice.ArtifactCollectingVisitor.visitArtifact(ArtifactCollectingVisitor.java:47)
at org.gradle.api.internal.artifacts.ivyservice.resolveengine.artifact.ArtifactBackedResolvedVariant$SingleArtifactSet.visit(ArtifactBackedResolvedVariant.java:150)
at org.gradle.api.internal.artifacts.ivyservice.resolveengine.artifact.ParallelResolveArtifactSet$VisitingSet$StartVisitAction.visitResults(ParallelResolveArtifactSet.java:100)
at org.gradle.api.internal.artifacts.ivyservice.resolveengine.artifact.ParallelResolveArtifactSet$VisitingSet.visit(ParallelResolveArtifactSet.java:69)
at org.gradle.api.internal.artifacts.DefaultResolvedDependency.sort(DefaultResolvedDependency.java:129)
at org.gradle.api.internal.artifacts.DefaultResolvedDependency.getModuleArtifacts(DefaultResolvedDependency.java:107)
at org.gradle.api.internal.artifacts.DefaultResolvedDependency.getAllModuleArtifacts(DefaultResolvedDependency.java:113)
at org.gradle.api.internal.artifacts.DefaultResolvedDependency.getAllModuleArtifacts(DefaultResolvedDependency.java:115)
at org.gradle.api.internal.artifacts.DefaultResolvedDependency.getAllModuleArtifacts(DefaultResolvedDependency.java:115)
at org.gradle.api.internal.artifacts.DefaultResolvedDependency.getAllModuleArtifacts(DefaultResolvedDependency.java:115)Ah thank you!
Siedlerchr
commented
11 months ago I stil wonder where this comes from or why gradle has issues there. Seems like it has troubles with getting the right variant.
mikepenz
commented
11 months ago Unfortunately that is something I don't have an answer to :/
mikepenz
commented
11 months ago Given the problem is unfortunately outside of the plugins capabilities. Closing. Please re-open if new details arise
About this issue
Building my app fails with a stack overflow error in collectDependencies If I change filterVariants to a non existing variant it works.
Project consists of a main "app" project and two libraries/modules
Details
com.google.android.gms:oss-licenses-plugin:0.10. com.google.android.gms:play-services-oss-licenses:17.0.1
Checklist