detekt: Changing any core class invalidates cached detekt classloader
Expected Behavior
Classloader gets invalided and a new gets created.
Observed Behavior
Confusing error message:
> Task :detekt-api:detekt FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':detekt-api:detekt'.
> Provided configuration file is invalid: Structure must be from type Map<String,Any>!
Steps to Reproduce
Add a line like settings.debug { "" } in Analyzer class and rerun gradle detekt.
Context
Plugin and core developers.
About this issue
- Original URL
- State: open
- Created 4 years ago
- Reactions: 1
- Comments: 24 (16 by maintainers)
detekt.use.worker.api=trueonly appears to solve issue partially, it does not solve the UP-TO-DATE checks.detekt.use.worker.api=true)Running with either
--rerunor old--no-daemonfixes the issue.Enable that by default is a different topic but one that I think that we should talk about. For that reason I created #6887. To me in this case the performance is the selling point.
I agree that correctness is really important but I would argue that only 0’1% of our users face this issue some times while 100% of them benefits from the performance boost. And now with the Workers we can have both 😃.
I was working on detekt yesterday all day without needing any
--stop. The stop is only needed if you run thedetekttask. In general is not a good idea to run detekt that often, it is slow and it’s OK to have code smells while you are coding. They should be gone only when you submit that code.Anyway, how would you rephrase the title? Any change on the core does make invalid the cached classloaders. I see the problem, usually invalidate means that the cache is not usable any longer so it will not be reused. But that’s not the case here. The cache is not valid but our code doesn’t spot it so we end up using invalid classloaders.
I am confused about the title of this issue.
It is currently: “Changing any core class invalidates cached detekt classloader”
But as was explained in #6425 , isn’t the issue precisely the opposite? We want the classloader to invalidate, but it currently is not.
I am here because I began creating my own custom rule, and I have the issue that every time I edit the code for the rule I have to use
gradle --stop. That should not be the case. Technically, my issue fits more with #6425 . That issue was closed in favor of this one, but the language for this issue is a little confusing so I am asking for some clarification.I think that #4128 will fix it. But I’m not sure.