checkstyle
Eclipse-CS does not refresh Checkstyle's External Resource list
While working on https://github.com/checkstyle/eclipse-cs/issues/454 ,
I noticed when I changed the regular expression header file and did a clean build to re-run Checkstyle, Eclipse-CS kept using the old header file not matter what I did to try to get it to see the new one.
Checkstyle did not recognize the new header file changes until I re-saved the Configuration file, even though it had no more changes at that point.
It seems to me Eclipse-CS is caching something in memory to avoid having Checkstyle recreate the config in memory for each run and is causing issues when it doesn't see something as changed.
Checkstyle's External Resource Info: https://checkstyle.org/writingchecks.html#Declare_check.27s_external_resource_locations
The issue is the way Eclipse-CS runs Checkstyle.
Auditor is basically the Checkstyle runner and the Checker instance it creates is cached throughout the life of multiple Checker runs until it is deemed out of date. It doesn't take into account external resources.
Checker assumes the instance is always re-created on a run, so Modules are never set to reload files they have loaded after the first time. There is no check for an external resource has changed. There is just loading and destroying. Header Check Example: https://github.com/checkstyle/checkstyle/blob/master/src/main/java/com/puppycrawl/tools/checkstyle/checks/header/AbstractHeaderCheck.java#L194-L197
For fixing this, it seems the only way may be to remove the cache on Checker in Eclipse-CS.
I doubt Checkstyle will want to build a reloading lifestyle that it currently doesn't support and also technically can't use in it's own run lifecycle. While checker manages the external resources from the configuration and modules, it only does so to pass that information to the internal cache it manages when it is enabled.
Maybe Eclipse-CS could make use of Checkstyle's caching module and use that to trigger a reset, but this isn't supported by RootModule's in general (which Eclipse-CS also doesn't support) and even if it was, it only supports giving a file string and does not provide any feedback that Eclipse-CS could really use.
