Menu
▾
▴
#159 Support for dynamically loading custom Checkstyle checks JAR
Would it be possible completely avoid the need to develop a custom Eclipse plugin, as described on http://eclipse-cs.sourceforge.net/#!/custom-checks, and instead offer a configuration / preference to load standard Checkstyle custom checkstyle module JAR dynamically, given simply an absolute location?
Once available, then https://github.com/m2e-code-quality/m2e-code-quality could set that to automatically match the dependencies added to the maven-checkstyle-plugin, and it would match the the Maven build. Imagine - automagic configuration that just works of Checkstyle in Eclipse identical to the command line!
Without this, and unless we develop an Eclipse plugin just because of 2-3 custom Checkstyle rules (which has to be built, distributed, maintained..), I'm blocked from further using Eclipse CS as part of https://github.com/vorburger/opendaylight-eclipse-setup because CheckstyleBuilder aborts with "Checkstyle-Plugin: cannot initialize module TreeWalker - Unable to instantiate 'org.opendaylight.yangtools.checkstyle.LoggerVariableNameCheck' class, it is also not possible to instantiate it as ...".
Perhaps implementing this would also clarify some things required for https://sourceforge.net/p/eclipse-cs/feature-requests/158/
👍
eclipse-cs integrates Checkstyle into the Eclipse runtime environment - which is an OSGI runtime. Hence all extensions need to be part of that runtime too - ergo OSGI bundles.
On the other hand the only activity to "develop a custom Eclipse plugin" is to augment the custom checks jar with an OSGI bundle manifest. Having done so that jar can be used in Maven as is - as well as an Eclipse plugin.
Deploying to extension jar to Eclipse is as easy as dropping the jar into a special folder.
Agreed, this doesn't work exactly as in the Maven build but still it is mostly a one time setup cost. Given that Maven build and Eclipse build work fundamentally different that's not too shabby IMO.
Apart from that, introducing another way of dynamically loading jars into an OSGI container without using OSGI mechanisms is a naughty idea, which can wreak all kinds of classloading mayhem. I certainly won't be doing that, even if the initial premise might sound tempting.
Lars, the problem in larger deployment, where the rules JAR may be part of a continously integrated moving target, and where there may be different versions of it, include deployment of that JAR to Eclipse IDEs. In an ideal world, if it could just be "picked up" from the project's Maven plugin classpath, that would "just work". Of course, that would require some classloader magic. It's "imaginable" (technically) to do, but would take some work - which is why I've never gotten to this.
PS: Lars, this is not a complaint, I'm grateful for you having made eclipse-cs at all; if I or anyway don't like it, we're free to propose code with enhancements!
PPS: Thomas FYI what I do now instead of this is to (try to.. time!) contribute custom useful general purpose check extensions to https://github.com/sevntu-checkstyle/sevntu.checkstyle - which can then, occassionally, release versions, incl. their Eclipse plugin with the extensions.
Hi Michael, I did not take it as a complaint, sorry if I came across that way.
The fundamental difference between Maven environment and Eclipse is that Maven execution is relatively short lived, so classloading stunts may not matter much, since the next execution is a new VM anyway.
The Eclipse instance however lasts several hours or even days (like for me, using hibernation to disk at days end). Here manipulating classloaders outside the intented runtime environment can only go wrong, introducing memory leaks, instabilities or other nasty effects.
Effectively what you're proposing means:
I am not saying it couldn't be done. I, personally, wouldn't know how, for starters.
In the end even if someone could do it, it would still be a violation of core OSGI principles. A big no-no in my book... :-)