Closed MariusVolkhart closed 2 years ago
Hey, thanks for your interest in this project!
I'm not entirely sure if this is a bug. Do you experience problems (apart from disk usage) with this behavior? For example, protobuf-gradle-plugin
does the same and keeps old classes after changing the .proto files.
className
is changed, all generated files belonging to it should be overriden by jextract
targetPackage
is changed, the source code (i.e. imports) must be updated to reflect this changeSearching the Gradle documentation, I also could not find a way to detect changes in properties during task execution and retrieve the old value. There is InputChanges
, however it only works with file properties.
No problems, no. Just seemed odd. Honestly, I initially started filing a feature request but then changed to a bug based on how I was phrasing the request. I think it's pretty rare that people change those values after the prototyping stage, so if you say "close, won't implement", I think that's reasonable.
The way I've seen other plugins do this is basically hashing their properties, and writing the files to a directory with the hash as a name. Then, on subsequent runs, they can see if any neighboring directories exist and delete them, since they indicate a different hash.
Also, thank you for making and publishing this plugin in the first place! It makes using jextract
in a real project a ton easier
Thanks for your input! I found an (very old) open issue at the protobuf-gradle-plugin
repository which discusses a similar topic (https://github.com/google/protobuf-gradle-plugin/issues/33).
The keypoints are:
build
directory (e.g. src
).DefaultTask#getOutputs
. Using it in a plugin could result in unexpected behavior in the future.Since, at the moment, it is only a matter of running gradle clean
to delete old source files and deleting whole directories outside the build tree is pretty risky, I would like to go the "close, won't implement" way for now. Although, I'm happy to accept any pull requests solving this issue in a elegant way.
I'm glad this plugin helps other people spinning up projects using jextract
! Also, thanks for using it! :slightly_smiling_face:
Environment
gradle-jextract
version: 0.2.4How does this bug occur?
When the output destination changes, such as when a new
className
ortargetPackage
is given, the previously-generated code remains untilclean
is run.What happens when the bug occurs?
Compilation proceeds with both the new and the old code.
Would you like to submit a PR fixing this bug?
[ ] YES [x] NO