Q:

Use of Paranamer in gradle to generate parameter name data

I am trying to get parameter names of class inside my android application. to supply input to a help() method which will print all methods available and its parameter type and names. To get the parameter name, i am trying to use paranamer jar. I added paranamer.jar as a module library and i am able to import and use it. But have no idea on how to plug into gradle in order to generate parameter name data. Anyone any help ?
Java code-
public void help() {
    Method[] declaredMethods = myclass.class.getDeclaredMethods();
    Paranamer paranamer = new CachingParanamer();
    for (Method declaredMethod : declaredMethods) {

        String[] parameterNames = paranamer.lookupParameterNames(declaredMethod, false);
//process paranamer.

    }
}

A:

Use their Ant task, Ant is neatly integrated in Gradle: https://docs.gradle.org/current/userguide/userguide_single.html#sec:using_custom_ant_tasks
Should be something like
configurations {
    paranamer
}

dependencies {
    paranamer 'com.thoughtworks.paranamer:paranamer-ant:2.8'
}

compileJava.doLast {
    ant.taskdef name: 'paranamer',
                classname: 'com.thoughtworks.paranamer.ant.ParanamerTask',
                classpath: configurations.paranamer.asPath
    ant.paranamer(classdir: destinationDir) {
        source.addToAntBuilder ant, 'fileset', FileCollection.AntType.FileSet
    }
}

I didn't test this, I don't use paranamer, I just made this up from the docs and source. destinationDir and source are not to be replaced by actual strings, but are the fields of the compile task.
I made this as an additional action to the compileJava task instead of an own task, because it modifies the class files produced by the compile task in-place and with a separate task it would involve copying the class files somewhere, running the paranamer and then caring that the modified files are packaged instead of the original files. If the paranamer task would modify the result of the compileJava task in-place, it would break incremental building, as then the compileJava task would always be out-of-date and run every time. The way I suggest it, it is part of the compileJava task and thus is done before the up-to-date check logic and thus should work flawlessly in this regard.
If you have multiple source sets or custom JavaCompile tasks and want to modify all of them, it would instead something like:
tasks.withType(JavaCompile) {
    it.doLast {
        ...
    }
}

