#524 checkstyle ant target and classpath attribute

release_4.4
closed
Oliver Burn
ANT Task (45)
5
2012-10-10
2008-09-08
Jerome David
No

If you have custom checks implemented in a jar, and you want to add that jar to the classpath for the checkstyle ant target, setting the classpath attribute doesn't work.

The Checker has the jar classes in its mLoader classloader, but the ModuleFactory uses Thread.currentThread().getContextClassLoader(), and this one doesn't.
A way to fix it is to set the current thread class loader to mLoader in finishLocalSetup:

if (mModuleFactory == null) {
//+++++++++++++++++++++++++++++++++++++++++++++++
Thread.currentThread().
setContextClassLoader(mLoader);
//+++++++++++++++++++++++++++++++++++++++++++++++
mModuleFactory =
PackageNamesLoader.
loadModuleFactory(
Thread.currentThread().
getContextClassLoader());
}

There seems to be the same problem in 5.0 beta.

Discussion

1 2 > >> (Page 1 of 2)
  • At least for Checkstyle 5.0 beta the custom jar must not be in the classpath attribute of the checkstyle task but on the system classpath (or ant launch classpath) - where the checkstyle-xx.jar is added to the classpath.

    The classpath attribute of the checkstyle ant task is used to specify the classpath of the source to be checked.

    Oliver, others - please correct me if I am wrong.

     
  • Lars Kühne
    Lars Kühne
    2008-10-21

    Custom checks should be in the same classloader as the checkstyle classes. For Ant tasks that means you have to include your own checks in the classpath attribute (or nested element) of the <taskdef> that defines the checkstyle task, not in the classpath of the <checkstyle> call.

    I can't test this right now, but it should look like this:

    <taskdef resource="checkstyletask.properties">
    <classpath>
    <pathelement location="checkstyle-all.jar"/>
    <pathelement location="customchecks.jar"/>
    </classpath>
    </taskdef>

     
  • Jerome David
    Jerome David
    2008-10-21

    And this is what is not working.
    Doing that adds the jar to the mloader classloader, not the context class loader that is actually used for the checks.

     
  • Lars Kühne
    Lars Kühne
    2008-10-21

    Ah, I see. Thanks for taking the time to clarify your problem, and yes this really should work - our own Ant task documentation recommends against adding stuff to Ant's global classpath.

    We have to be a bit careful about changing this code. I think I remember some classloader changes were introduced for the Eclipse plugin, we need to find a solution that works both in Ant and Eclipse.

    lkoe, do you have the time to look into this?

     
  • I will look into it, but possibly not before the weekend (currently building a new home-office system).

    Probably the fix will be in CheckstyleAntTask itself, where the classloader used for module loading is set.

    365 final ClassLoader moduleClassLoader =
    366 Checker.class.getClassLoader();
    367 context.add("moduleClassLoader", moduleClassLoader);

    Currently this is the classloader which loaded the Checker class, and I thought that would be the one that also contains the extension module.
    But supposedly I was wrong.

    Changing that particular code is uncritical to the eclipse-cs plugin, since it sets its own moduleClassLoader onto the Checker instance.

     
  • I will look into it, but possibly not before the weekend (currently building a new home-office system).

    Probably the fix will be in CheckstyleAntTask itself, where the classloader used for module loading is set.

    365 final ClassLoader moduleClassLoader =
    366 Checker.class.getClassLoader();
    367 context.add("moduleClassLoader", moduleClassLoader);

    Currently this is the classloader which loaded the Checker class, and I thought that would be the one that also contains the extension module.
    But supposedly I was wrong.

    Changing that particular code is uncritical to the eclipse-cs plugin, since it sets its own moduleClassLoader onto the Checker instance.

     
  • I just tried using the Ant Task with a custom check jar and it just seems to work (CS 5.0 beta).

    Just as lkuehne described I added the jar to the taskdef classpath.
    The custom check gets picked up and works as expected.

    Could you please be more specific about your actual problem - e.g. a exception stack trace?
    Have you augumented your custom jar with a checkstyle_packages.xml file as described here:
    http://checkstyle.sourceforge.net/5.x/config.html#Packages

     
  • Jerome David
    Jerome David
    2008-10-26

    I am afk for 3 weeks. I will check when I get back. Thanks for looking into it.

     
  • Jerome David
    Jerome David
    2008-11-19

    Example of failing targets

     
    Attachments
  • Jerome David
    Jerome David
    2008-11-19

    I have written an little example (checkstyle-ant.zip in attachment).
    I have a very simple custom check in test.checkstyle.CustomCheck.

    In build.xml:
    target: check fails all the time (obviously it means that the changes I mentioned aren't enough).
    target: check2 fails with the official jar, but not with the jar containing the modifications that I mentioned.

    check uses taskdef
    check2 uses the classpath attribute

    Maybe I am doing something wrong, but I can't see what it is.
    File Added: checkstyle-ant.zip

     
1 2 > >> (Page 1 of 2)