Although I clear the usual suspects - listed below - gradle continues to use outdated info about the dependencies, or sometimes the content, of my build. For example, I update the version of a dependency but gradle ignores the change. There must be somewhere else build data is being kept, but where?
Usual suspects: Remove ‘build’ folder, either directly or with ‘gradle clean’. Use --rerun-tasks and/or --refresh-dependencies. Actually remove ~/.gradle/caches and ~/.m2. Run ps-aef to find running gradle processes and kill them. Delete ‘workingDirectory’/.gradle. This is on a relatively new macbook pro with gradle 2.5.
What I’m changing is sometimes dependency versions, sometimes task contents that make a difference in actual up-to-date-ness. Is there anywhere else that gradle keeps notes to itself?
This is a subproject in a multimodule build. It may be that I need to ‘rm -fr …/.gradle’ as part of my standard incantation for starting fresh. I’ll try that.
copyFromConfig is then not run - gradle thinks it ‘up to date’ - even though the build directory into which its output goes is gone and the .gradle directory in the master project has been removed. The copy task simply copies certain jars from a dependency configuration into a folder with the build directory. How do I convince gradle to rerun the task?