Closed garyrussell closed 2 years ago
I am not sure why, but it looks like the rename in schemaZip avoids the duplicate zip entries deprecation fixed in other projects.
It's not the rename - I just added that to the SIK build but we still get duplicate zip file entries.
In summary, I am not sure why we don't have duplicates in the schema zip; diagnostics show we run the into
multiple times for each schema.
I'm not sure what you want to hear from me, but I'm OK with whatever you can make to PR the fix for this issue.
Thanks
Hehe - one of us has to study https://docs.gradle.org/6.2.2/userguide/viewing_debugging_dependencies.html#sub:resolving-unsafe-configuration-resolution-errors
I doubt my groovy skills are up to it.
we have that "compileClasspath was resolved without accessing the project in a safe manner." from the dokka
.
I've copied classpath += files(javaProjects.collect { it.sourceSets.main.compileClasspath })
from Spring Framework: https://github.com/spring-projects/spring-framework/blob/master/gradle/docs.gradle#L70
Looks like we definitely need those jars for the proper k-docs generation, but I have no idea how to collect dependencies to honor Gradle requirements. It was really safe before...
Or we need to wait when SF resolves this issue or we just ask Gradle team how to resolve this issue. 😄
I have been playing with it; getting close 😄
Has been fixed with these commits:
https://github.com/spring-projects/spring-integration/commit/761ccf2ed2ff17e26f062da864df60bd36668d18 https://github.com/spring-projects/spring-integration/commit/0ebd076637c17670b72a4c2f2ab0b4ee4a93f789 https://github.com/spring-projects/spring-integration/commit/adb52baa9516e5c87b47cf5c031d7460c4c6ab09
I am not sure why, but it looks like the
rename
inschemaZip
avoids the duplicate zip entries deprecation fixed in other projects.These deprecations remain.