Jendrik Johannes <******@****.***> 1607501645 +0100

Jendrik Johannes <******@****.***> 1607501645 +0100

Jendrik Johannes <******@****.***> 1607501645 +0100

Jendrik Johannes <******@****.***> 1607501645 +0100

Jendrik Johannes <******@****.***> 1607501645 +0100

Jendrik Johannes <******@****.***> 1607501645 +0100

This has also forced plugins written in languages other than Groovy to use Groovy types for some APIs.

When the Kotlin DSL was introduced, we made an effort to add non-Groovy equivalents for all APIs.
This has been mostly done, but there remain a few holdouts (fixing these is out of scope).

To keep the Groovy DSL ergonomic, we generate methods as necessary from the non-Groovy equivalents.

Doing this provides the following specific benefits:

 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

plugins {
    id("java-library")
    id("groovy-gradle-plugin")
    id("gradlebuild.code-quality")
    id("gradlebuild.ci-reporting")
    id("gradlebuild.test-retry")
    id("gradlebuild.private-javadoc")
}

java.configureJavaToolChain()

dependencies {

 */

package gradlebuild.codenarc.rules;

import org.codehaus.groovy.ast.ASTNode;
import org.codehaus.groovy.ast.ClassNode;
import org.codehaus.groovy.ast.MethodNode;
import org.codehaus.groovy.ast.expr.Expression;
import org.codehaus.groovy.ast.expr.MethodCallExpression;
import org.codehaus.groovy.ast.expr.PropertyExpression;
import org.codehaus.groovy.ast.expr.VariableExpression;
import org.codenarc.rule.AbstractAstVisitor;

    the<SourceSetContainer>().all {
        tasks.register<Checkstyle>(getTaskName("checkstyle", "groovy")) {
            config = configFile("checkstyle-groovy.xml")
            source(allGroovy)
            classpath = compileClasspath
            reports.xml.outputLocation = checkstyle.reportsDir.resolve("${******@****.***}-groovy.xml")
        }
    }
}

codenarc {
    config = configFile("codenarc.xml")