This message was deleted.
# community-support
s
This message was deleted.
v
Because there is no "version of 'foo.bar.xyz' that satisfies the version constraints"? Maybe if you do not crop the remaining error message you can get more elaborate help. 🙂
e
Thanks for the response @Vampire 🙂 The message is long, and basically prints out 9 different versions of the library What I don’t get is that I already create a strict version (that being included in the error message as well) in a platform module that has no issue until now. I’m not exactly sure how can I satisfies the constraints.
If it helps, here’s the more elaborate error message
Copy code
> Could not resolve all task dependencies for configuration ':home:debugUnitTestRuntimeClasspath'.
Could not resolve <http://foo.bar.xyz:mymodule:1.0.0|foo.bar.xyz:mymodule:1.0.0>.	
     Required by:	
         project :home-page	
         project :home-page > project :bom	
         project :home-page > <http://foo.bar.xyz:feature-module:1.0.0|foo.bar.xyz:feature-module:1.0.0>
      > Cannot find a version of '<http://foo.bar.xyz:mymodule|foo.bar.xyz:mymodule>' that satisfies the version constraints:	
           Dependency path 'home:unspecified' --> 'home:unspecified' (debugRuntimeElements) --> '<http://foo.bar.xyz:mymodule:1.0.0|foo.bar.xyz:mymodule:1.0.0>'	
           Dependency path 'home:unspecified' --> 'home:unspecified' (debugRuntimeElements) --> 'bom:unspecified' (runtimeElements) --> '<http://foo.bar.xyz:mymodule:1.0.0|foo.bar.xyz:mymodule:1.0.0>'	
           Constraint path 'home:unspecified' --> 'home:unspecified' (debugRuntimeElements) --> 'bom:unspecified' (runtimeElements) --> '<http://foo.bar.xyz:mymodule:{strictly|foo.bar.xyz:mymodule:{strictly> 1.0.0}' because of the following reason: Strictly enforced by bom. Please check with the team if there's an issue	
           Dependency path 'home:unspecified' --> 'home:unspecified' (debugRuntimeElements) --> '<http://foo.bar.xyz:home-contracts:1.0.0|foo.bar.xyz:home-contracts:1.0.0>' (runtime) --> '<http://foo.bar.xyz:mymodule:1.0.2|foo.bar.xyz:mymodule:1.0.2>'
I’m trying to resolve
debugUnitTestRuntimeClasspath
configuration while the constraint in
runtime
and
runtimeElements
(?)
v
Can you maybe share a build
--scan
?
e
Sorry I can’t give the whole build scan. But I can look where you point me 🙂
v
Well, it provides usually pretty good information which dependency comes from where and why. But hard to point to where to look at specifically. Maybe you can at least provide the full "prints out 9 different versions of the library" output without redcation, either here or if too big via some paste-service like pastebin.com?
e
Here’s the console output
v
Hm, seems a bit strange as there is only one
strictly
in the output. Do you by any chance use the Spring dependency-management Gradle plugin? Because that one can easily lead to such strange resolution problems and shouldn't be used either way. Even its developer says so. 🙂
e
Hm, seems a bit strange as there is only one
strictly
in the output.
Just to confirm, so normally above error will happen if there’s a conflict between constraints right?
Do you by any chance use the Spring dependency-management Gradle plugin?
I’m not, it’s an Android project 😅 , nice info anyway So should I raise an issue in Gradle repo? FYI It’s fixed for now, will try to compare the build scans tomorrow
v
Just to confirm, so normally above error will happen if there’s a conflict between constraints right?
Yeah, those errors for example happen if two different version are required "strictly" as this cannot be resolved then for example.
So should I raise an issue in Gradle repo?
I guess the first step would be to knit an MCVE, otherwise it will also be hard for the Gradle guys to say or do anything. Once you have one, you could also first share it and and a build
--scan
of it here, so someone might give an advice, or you can open an issues on the Gradle repo if you are sure it is actually a Gradle bug. 🙂
e
Thanks for the suggestion, you are certainly the most helpful person in this Slack 😄 I’m not sure I will able to create MCVE, since I cannot understand the issue myself. The workaround to unblock the build was to set the version to the latest one, not exactly a fix Although, I will create a support ticket for this and share the result to this thread.
👌 1
We noticed that our issues are all related to
debugUnitTestRuntimeClasspath
and we resolved this issue by adding our platform project to
testImplementation
configuration. I still cannot explain why this happens, even the Gradle team in our support ticket still remains puzzled. It might be Android Android-specific issue, or it might also specific to our setup only (because we have a custom project and artifact-swapping plugin). Once again, thanks @Vampire
👌 1