kotlin2 in Debian -- 2025W22 update

[Julien Plissonneau Duquène <sre4ever@free.fr>]

Good evening,

This week was mostly spent debugging. Fortunately I could finally figure 
out what the issue was with transitive dependencies.

Le 2025-05-23 20:04, Julien Plissonneau Duquène a écrit :
> despite my custom dependency rewriting logic (that is not even executed 
> in this case)

It was in fact "because of", not "despite". Part of that logic works by 
creating new dependencies and remove existing ones, as in some places 
the gradle documented API doesn't offer a way to replace group and 
artifact names. There were several defects in that logic that are now 
fixed:
- I use null as a return value that means "do not rewrite replace the 
dependency" (because it's actually the same, or some other issue 
happened). But I also implemented a cache that doesn't allow the storage 
of null values, and at some point forgot to implement the null value 
thing when the value was obtained from the cache. As a result, the 
dependency would still be replaced, but only starting from the second 
call to the function. This made finding the root cause a bit more 
challenging ^ ^
- the replacement dependency did not retain all the properties of the 
initial target, and among these transitivity and exclusion rules. They 
were not needed in gradle's build, and DependencyHandler.create() 
returns an object of the Dependency type, which is actually an interface 
that doesn't expose these properties, so I didn't go further at that 
time. This is what caused the issue: the dependency was properly 
declared as being non-transitive in build scripts, but the custom plugin 
replaced it with the same dependency, without setting the replacement as 
non-transitive.
- while I was at it I investigated a previous issue I had with equals() 
between Dependency objects, and found that it's probably a bug in 
Gradle's implementation.

I also discovered that there is an interesting `resolveDependencies` 
task implemented in Kotlin build scripts. It has some issues, but it 
will help with mapping the full dependency set.

After shedding some more Android dependencies the build now fails a bit 
closer to the point where Gradle would start actually building the 
project, but it's still not there yet.

Cheers,

--
Julien Plissonneau Duquène