https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# dependency-management
s
This message was deleted.
t
Example of such substitution
v
I think you cannot, especially not only for transitive dependencies. If it is a project in the same build (not from a composite build) the higher version is used, so if the binary dependency has a higher version it is used, if the project has a higher version that used. You can change such behavior on a configuration level so that always the projects are used regardless the version. If it is a project from an included build, it will always use the project from the included build, regardless the version. And you can change that behavior on a configuration level to disable the usage of global substitution rules.
Afair that is about what you can configure. So maybe you could try by using a strict version, or making sure the version of the project is lower than the version of the binary dependency or something like that.
t
declaring strict version works, but I need explicit add each transitive dependency with strict version constraint. Generally I wonder if such project substitution should work for build classpath
v
Obviously 😄
Well, hm, maybe not
t
I mean it should be disabled for build classpath )
v
Yes, I know what you meant
Is it coming from an included build, or is it a project within the same build?
I'd wonder if it would be taken when coming from the same build, due to hen-and-egg
t
error happens in the included build which enabled via 
settings/pluginManagement.includedBuild()
. Substituted project is located in the main project
v
So you have the main build that 
include(":kotlin-gradle-plugin")
and 
includeBuild("gradle-build-conventions")
right?
And you do not 
includeBuild(..)
(or where you have the main build relative to the conventions build) in the conventions build, do you?
Because if you do, that is most probably the bad cycle making problems.
Maybe you can try to knit a reproducer and then either have something to report or find your error on the way. 🙂
I looked for your branch, but it seems you didn't push it yet
t
yeah, haven't pushed - will do once I figure out all the problems
And you do not 
includeBuild(..)
(or where you have the main build relative to the conventions build) in the conventions build, do you?
No, build conventions do not depend on the main project, just on published bootstrap artifacts
v
Yeah, it's easily reproducible that it uses that substitution, even though it seems to work in my play project.
I'd recommend you open an issues about that with a simple reproducer. I'm not sure whether this is intended, but it seems strange to me too.
t
I will finalize my changes with workaround and then open an issue based on the reproduction in 
kotlin.git
repo 🙂
v
Ah, within the plugin build it does not use the substitution but the external dependency. Only within the including build it then substitutes, that's at least better than what I feared.
But then it might be expected
Yeah, it's exactly that highest-version wins logic. If the version of the project is less than the dependency, the dependency is used, if the project version is higher, the project is used instead and you can just say "use always the project".
Even strict version in the plugin build does not work here
t
as strict version somehow helps - I highly suspect it is higher version wins situation
v
Not here (strict helping)
Even 
_resolutionStrategy_.force
in the buildscript block does not help here
t
yep, I think I've tried everything and only:
Copy code
version { strict(kotlinBootstrapVersion) }
helps 😢
v
I'm curious what the Gradle folks will say to it
t
finally had time to create related issue: https://github.com/gradle/gradle/issues/26876
👌 1
17 Views
Open in Slack
PreviousNext
Powered by