https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# dependency-management
s
This message was deleted.
p
No, it should map the order declared in your build file 🤔
c
Not sure that’s the case as there are multiple contributors to the class path, transitive dependencies, etc. is it possible that the os/file system plays into this? Used to wrestle with that for Spring Boot apps running exploded during development vs packaged for deployment, until the launch class path was normalized https://stackoverflow.com/questions/67997151/spring-boot-inner-jar-files-loading-order-embedded-tomcat
v
As far as I'm aware it should not be random, but deterministic, consistent, and based on the order the dependencies are added. But anyway, imho it is best to remove the need to rely on classpath ordering by making sure you don't have classes in multiple jars. Put everything on the module path, then you are technically forced to prevent even split packages. :-D
t
Yeah, yeah, I know the theory..., but then we have players like this: https://youtrack.jetbrains.com/issue/KT-64774
I'll create a repro, because I also thought it should be based on the declaration order, and then something like in-order/pre-order/depth-first traversal of the dependency tree.
👌 1
v
Isn't that only meant for direct execution and if you want to use it embedded you should use 
kotlin-compiler-embeddable
?
t
Yeah, tell that to Igor 🙂
v
Igor, do it
Let's see whether he follows here :-D
t
😄 I sent him a ref to this issue in private.
There's also a few recent versions of kotlin (some of 1.8 / 1.9) where something was not shaded, and that caused a problem maybe with buildscript.classpath, don't remember exactly.
v
Damn fat jars, I really hate them. And even more if libs are fat jars.
🙏 2
t
3 Views
Open in Slack
PreviousNext
Powered by