https://gradle.com/ logo
Join Slack
Powered by
Not sure if this is a known issue, but I hit a pro...
# community-support
s
Not sure if this is a known issue, but I hit a problem with the build cache after changing the name of a sub-project. I had a project nested under my parent project and referenced it in the 
settings.gradle
file like this:
Copy code
rootProject.name = 'my-service'
include ':public-api'
project(':public-api').name = 'my-service-public-api'
but then I decided to do things differently and changed that to simply:
Copy code
rootProject.name = 'my-service'
include ':public-api'
but the build cache was confused. The 
public-api
sub-project is generating Java code from Smithy specifications. It seems that the 
spotless
code formatting plugin was now stuck looking at the old path for the generated code because of the build cache. Clean builds didn't help, I had to manually delete 
~/.gradle/caches/build-cache-1
. Is this a Gradle problem or a spotless plugin problem? (or a me problem? šŸ™ )
v
Running the task with 
--rerun
should have helped I think, at least I mean to remember it would also update the build cache entry. Anyway, if a build cache entry is wrongly reused, that usually means that the tasks inputs are not declared properly. You can enable the cache debugging to see exactly what becomes part of the cache fingerprint. But I'm not sure what you mean exactly. You didn't change paths, did you? You only changed the project name. I usually use the final name and then set the project dir, but doing it like you did should afair also work.
s
The Smithy outputs changed their destination folder based on the project name. That's just the default path for the smithy plugin outputs. 
./public-api/build/smithyprojections/<project-name>/codegen/java-codegen/java/<package-path>/*.java
v
Can you show an MCVE? I tried to reproduce with a simple task implementation but wasn't able to. If I change the setting script, the classpath of the task changed and thus the task is re-executed and not taken from cache.
s
Try this... build it, then edit it to not change the sub-project name and run a clean build
gradle-cache.zip
v
Works without problem
But also does not use the cache
> Task cache issue public apismithyBuild
Caching disabled for task 'cache issue public apismithyBuild' because:
Build cache is disabled
Caching has not been enabled for the task
Task 'cache issue public apismithyBuild' is not up-to-date because:
Output property 'outputDir' file D:\Sourcecode\other\others\gradle_bug\public-api\build\smithyprojections\cache-issue-public-api has been removed.
Output property 'outputDir' file D:\Sourcecode\other\others\gradle_bug\public-api\build\smithyprojections\cache-issue-public-api\codegen has been removed.
Output property 'outputDir' file D:\Sourcecode\other\others\gradle_bug\public-api\build\smithyprojections\cache-issue-public-api\codegen\build-info has been removed.
and more...
Running smithy build
And even if enable build cache, still the task is not cacheable anyway. So I really cannot follow what problem you have with that MCVE.
Besdies that as provided it does not even build due to Spotless
If you provide someone that is trying to help you in his sparse spare time an MCVE, you should really make sure it fulfills the C and V.
s
> Besdies that as provided it does not even build due to Spotless šŸ¤” It builds for me??
BUILD SUCCESSFUL in 1s 17 actionable tasks: 11 executed, 4 from cache, 2 up-to-date Configuration cache entry stored
Okay.. unzipped what I posted and trying that version I got an issue... trying to figure out what I messed up.. sorry.
Copy code
* What went wrong:
Execution failed for task ':cache-issue-public-api:compileJava' (registered by plugin class 'org.gradle.api.plugins.JavaBasePlugin').
> Cannot access input property 'stableSources' of task ':cache-issue-public-api:compileJava'. Accessing unreadable inputs or outputs is not supported. Declare the task as untracked by using Task.doNotTrackState(). For more information, please refer to <https://docs.gradle.org/9.7.0-rc-1/userguide/incremental_build.html#sec:disable-state-tracking> in the Gradle documentation.
Is that what happened to you? (This is the first time I've seen anything like that error) I even diffed the folders where I am successfully compiling, and the unzipped version I gave you. They are the same. Very weird.
Ah.. sorry the missing bit.. I have enabled the build cache in my per-user settings: ā”‚ File: ~/.gradle/gradle.properties ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ā”€ 1 ā”‚ # Gradle properties 2 ā”‚ org.gradle.parallel=true 3 ā”‚ org.gradle.caching=true
v
Is that what happened to you? (This is the first time I've seen anything like that error)
No, as I said, Spotless complained about something.
Ah.. sorry the missing bit.. I have enabled the build cache in my per-user settings:
That's quite dangerous. Not every build is capable of proper caching, let alone parallel execution. I would never enable those generally but always build specifically. With having it in you user file, you might run builds with these settings in that are not compatible with them, and build you sister with others that could use them don't do when others run them. Unless of course, if you never run anyone else's builds and never share any build. Anyway, as I said I also tried with caching enabled (unlikely it is parallel specific), and still got no problem, and the task also still is not cacheable anyway.
s
Well this is strange. I can't reproduce your problem and you can't reproduce mine. šŸ¤· I'm able to reproduce it consistently and get no issues from spotless. I will fix my users settings... I just put the settings there to try it out without modifying all our projects and forgot about it because it was working. šŸ‘ Using 
--rerun-tasks
works, so there is no need to manually delete the build cache. I'm not going to spend any more time on it. Thanks for trying!
v
You are probably on *nix. I tried on Windows. The Spotless check complains that the 
Library.java
coming from the zip has LF EOL, while it expects CRLF EOLs which per-se is a quite non-sense check imho. šŸ¤·ā€ā™‚ļø
šŸ¤¦ 1
s
Yes, that would be the issue. I agree, that's a dumb check. I also wish Windows would just phase out CR/LF line endings. I wonder what would happen if Amiga's were still a thing , I believe they used CR line endings šŸ˜†.
5 Views
Open in Slack
PreviousNext
Powered by