Unfortunately I don't think a workaround in eclipse-cs is feasible (or even possible). In my eyes the current classpath scanning implementation offers no practical benefit over the long standing previous implementation while adding serious drawbacks. I hope the points brought forward are sufficient to convince the Checkstyle team to revert this change.
Created https://github.com/checkstyle/checkstyle/issues/4916 - it appears as if a classpath scanning feature introduce in Checkstyle core recently cannot possibly work in Eclipse.
For reference I ended up in https://github.com/checkstyle/checkstyle/blob/master/src/main/java/com/puppycrawl/tools/checkstyle/utils/ModuleReflectionUtils.java#L55 which does not pick up the custom check classes in Eclipse.
Yes, indeed the error message was misleading. I did half an hour of debugging today and from what I can deduce there is something off with the classpath scanning for check class, introduced with https://github.com/checkstyle/checkstyle/issues/3607 However, I couldn't get to the bottom of this just yet - will need more time
I create https://github.com/checkstyle/checkstyle/issues/4885
Possibly this change to PackageNamesLoader: https://github.com/checkstyle/checkstyle/commit/ddeb553834f10570089a033fa1ac1501b74ac358
Hi, I assume this to be related to a Checkstyle-internal change concerning the handling of checkstyle_packages.xml files. Please note in the Exception message that there is a dot missing between the package and class name which Checkstyle core constructs from the checkstyle_packages.xml and the check name from the loaded configuration, e.g. com.puppycrawl.tools.checkstyle.checks.annotationJsr305Annotations Please check with the Checkstyle core project where this change comes from. If my theory holds...
.@Aditya I couldn't reproduce at first glance, please provide steps - preferably in a bug ticket. Judging from the location of the NPE a full clean/rebuild of your workspace might help.