https://gradle.com/ logo
Join Slack
Powered by
I've run into a problem that I'm not totally sure ...
# community-support
s
I've run into a problem that I'm not totally sure how to fix. I have a module that I renamed and after I renamed it, my ci pipeline jobs started failing. The name before was camel case, 
fooBar
, and then I changed it to be all lower case, 
foobar
, and this caused the issues. Things seem to work fine locally so I was thinking the problem was from the caching, but I've tried to remove/clear/update the ci and gradle caching, but I'm not having any luck. The error is
Copy code
* What went wrong:
Could not determine the dependencies of task ':example:jvmTest'.
> Could not resolve all task dependencies for configuration ':example:jvmTestRuntimeClasspath'.
   > Could not resolve project :foobar.
     Required by:
         project :example
      > No matching configuration of project :foobar was found. The consumer was configured to find a library for use during runtime, preferably optimized for standard JVMs, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'jvm' but:
          - None of the consumable configurations have attributes.
i still think it might have to do with the caching but I've set 
org.gradle.caching
and 
org.gradle.configuration-cache
to false, and I'm not using a build cache either. I will post the abbreviated stack trace in the thread. Can anyone give me some ideas of how I can fix this?
Copy code
* Exception is:
org.gradle.api.internal.tasks.TaskDependencyResolveException: Could not determine the dependencies of task ':example:jvmTest'.
	at org.gradle.api.internal.tasks.CachingTaskDependencyResolveContext.getDependencies(CachingTaskDependencyResolveContext.java:68)
	at org.gradle.execution.plan.TaskDependencyResolver.resolveDependenciesFor(TaskDependencyResolver.java:49)
	at org.gradle.execution.plan.LocalTaskNode.getDependencies(LocalTaskNode.java:148)
	at org.gradle.execution.plan.LocalTaskNode.resolveDependencies(LocalTaskNode.java:122)
...
	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
	at org.gradle.internal.concurrent.AbstractManagedExecutor$1.run(AbstractManagedExecutor.java:47)
Caused by: org.gradle.api.internal.artifacts.ivyservice.DefaultLenientConfiguration$ArtifactResolveException: Could not resolve all task dependencies for configuration ':example:jvmTestRuntimeClasspath'.
	at org.gradle.api.internal.artifacts.ResolveExceptionContextualizer.mapFailure(ResolveExceptionContextualizer.java:81)
	at org.gradle.api.internal.artifacts.ResolveExceptionContextualizer.mapFailures(ResolveExceptionContextualizer.java:60)
...
	at org.gradle.internal.graph.CachingDirectedGraphWalker.doSearch(CachingDirectedGraphWalker.java:121)
	at org.gradle.internal.graph.CachingDirectedGraphWalker.findValues(CachingDirectedGraphWalker.java:73)
	at org.gradle.api.internal.tasks.CachingTaskDependencyResolveContext.getDependencies(CachingTaskDependencyResolveContext.java:66)
	... 143 more
Caused by: org.gradle.internal.resolve.ModuleVersionResolveException: Could not resolve project :foobar.
Required by:
    project :example
Caused by: org.gradle.internal.component.NoMatchingGraphVariantsException: No matching configuration of project :foobar was found. The consumer was configured to find a library for use during runtime, preferably optimized for standard JVMs, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'jvm' but:
  - None of the consumable configurations have attributes.
	at org.gradle.internal.component.ResolutionFailureHandler.noMatchingGraphVariantFailure(ResolutionFailureHandler.java:313)
	at org.gradle.internal.component.model.GraphVariantSelector.selectDefaultConfiguration(GraphVariantSelector.java:155)
	at org.gradle.internal.component.model.GraphVariantSelector.selectVariants(GraphVariantSelector.java:86)
...
	at org.gradle.api.internal.artifacts.configurations.ResolutionBackedFileCollection.visitDependencies(ResolutionBackedFileCollection.java:57)
	at org.gradle.api.internal.tasks.CachingTaskDependencyResolveContext$TaskGraphImpl.getNodeValues(CachingTaskDependencyResolveContext.java:103)
	at org.gradle.internal.graph.CachingDirectedGraphWalker$GraphWithEmptyEdges.getNodeValues(CachingDirectedGraphWalker.java:213)
	at org.gradle.internal.graph.CachingDirectedGraphWalker.doSearch(CachingDirectedGraphWalker.java:121)
	at org.gradle.internal.graph.CachingDirectedGraphWalker.findValues(CachingDirectedGraphWalker.java:73)
...
	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
	at org.gradle.internal.concurrent.AbstractManagedExecutor$1.run(AbstractManagedExecutor.java:47)
v
What OS do you and CI use?
s
I'm on a Mac M1 running Sonoma 14 and the ci is running Ubuntu 20.04.6
v
afair macOS filesystem is case insensitive. Ubuntu filesystem is case sensitive. At least those are the defaults. So you probably missed to rename some bit, or did not get it recorded in Git properly and locally is just works because of case-insensitivity.
Make sure the renaming was done everywhere properly.
Maybe this would have saved you: https://github.com/gradle/gradle/issues/27379
s
hm ok. the actual folder name of the module on disk has always been lower case but it was just referenced with the camel case in the gradle scripts so it feels more like an issue with gradle. i did a more thorough check of the project and there are no references to the camel case module name anywhere.
v
git ls-tree -r @
s
ah, yeah the module name is camel case when i run that
v
Yep, so just like I assumed
On mac it doesn't matter because of case-insensitive file system
On Ubuntu it worked because it was correct, camel-case in path and camel-case in settings script
By changing it to lowercase in the settings script only it still works for you because of case-insensitive, but fails on Ubuntu where it does not match anymore
And as I said, that feature request would have saved you, or made you reallize earlier that there is a problem
So either change it back to camel-case in the settings script, or change the actual paths in Git to be lower-case, so that it is again consistent for case-sensitive file system
Or reconfigure the Ubuntu system to use a case-insensitive filesystem. 😄
(don't)
s
haha ok. I'm going to try and update git to make it see the lower case name. thanks for the info!
👌 1
v
Easiest - besides doing it on a case-sensitive file system - probably is to rename to something completely different and then to the lowercase name
s
yeah i went from the camel case to a temp name and then from the temp name to the lower case name. things look promising now
👌 1
5 Views
Open in Slack
PreviousNext
Powered by