Add support for Gradle

[uschindler]

The Elasticsearch people started with https://github.com/elastic/forbidden-apis-gradle-plugin.

I think this should be included directly into the forbidden-apis tool. Basically this is more or less the Maven tool, just implemented as Gradle's DefaultTask extension. This can be implemented in pure Java, this is what I would prefer.

As usual all would be packaged in the same JAR file because there are no conflicts between the tools.

[uschindler]

I added a new branch: https://github.com/policeman-tools/forbidden-apis/compare/issue68

[rjernst]

Looking good, thank you!

Could you possibly make the plugin work with all sourceSets? This would allow eg. adding a new testInteg which is also checked?

[uschindler]

Hi @rjernst,
The problem with all sourcesets is that Gradle has no "process-classes" like Maven. To ensure that it starts, you need some task where you can add it as dependency. For unknown sourcesets this does not work (no defined)

In that case you would need to configure the task on your own, which should work with plain gradle/groovy. The class is there, you just have to define 2 things: classesDir + classpath.

By the way, the current version that was committed to the branch works correct now. I have several Gradle projects from the examples shipped with gradle extended by this plugin, works.

Are there any plans to switch Elasticsearch builds to Gradle?

[uschindler]

This is an example (modify Gradle's samples/java/quickstart example):

apply plugin: 'java'

buildscript {
  repositories {
    mavenLocal()
  }
  dependencies {
    classpath 'de.thetaphi:forbiddenapis:1.9-SNAPSHOT'
  }
}

apply plugin: 'de.thetaphi.forbiddenapis'

sourceCompatibility = 1.5
version = '1.0'
jar {
    manifest {
        attributes 'Implementation-Title': 'Gradle Quickstart',
                   'Implementation-Version': version
    }
}

repositories {
    mavenCentral()
}

dependencies {
    compile group: 'commons-collections', name: 'commons-collections', version: '3.2'
    testCompile group: 'junit', name: 'junit', version: '4.+'
}

test {
    systemProperties 'property': 'value'
}

forbiddenApis {
  signatures = ['java.lang.String']
  bundledSignatures = ['jdk-unsafe','jdk-deprecated']
  failOnViolation = false
}

testForbiddenApis {
  signatures = ['org.gradle.Person']
  bundledSignatures = ['jdk-unsafe','jdk-deprecated']
  failOnViolation = false
}

uploadArchives {
    repositories {
       flatDir {
           dirs 'repos'
       }
    }
}

[uschindler]

I changed the task dependencies in the branch a bit (after sleeping about it):
the new forbidden tasks are now dependencies of the "classes" and "testClasses" generic tasks. This is similar to Maven. So every task that requires class files gets the checked ones. Our tasks only depend on java compilation tasks.

I am currently investigating why the forbidden-checks run all the time although there are no changes. I tried to add outpus == inputs, but this did not help.

[uschindler]

I refactored the task now, so inputs/outputs work correctly. The issue was that annotation don't work correctly on fields without getters. I also changed the task to be PatternFilterable, so it now behaves similar to other tasks taking input files,

[rjernst]

Why not just install the tasks and let he user decide what should depend on them? It is really simple for the user to eg add it to check:

check.dependsOn forbiddenApis, testForbiddenApis

In my particular case, I want to add a precommit task, and have forbidden apis as part of that, and precommit be part of check. This would allow eg forbidding System.out.println, but still be able to run the tests directly when debugging with print outs. But a full build or check call would still do the forbidden checks. I realize you could do this through setting a system property to the failOnViolation, but why restrict the user to a single way of using the api, instead of allowing them to easily customize how they want to use it?

[uschindler]

Hi,
I did it the way how it is at the moment mostly because the current Maven plugin's MOJO is also located in the phase called "process-classes" (and because @pickypg did it the same way in his plugin).
My proposal would be: As many people already complained about that (or changed the defaults in ther Maven config to use the "verify" phase), I would do the following:

• release the Gradle plugin as forbiddenapis 2.0 (instead 1.9)
• change the Maven plugin to use the "verify" phase by default
• In the Gradle plugin let "check" (is same as "verify" phase in Maven) depend on forbidden-apis. This brings more convention as Gradle proposes and its ran by default. Also other Gradle plugins like CheckStyle or PMD have the same defaults! To disable the automatic assignement, we could add a parameter to the plugin initialization, so you can disable this. But for new users we really should "automatically" configure dependency tree correctly (just later phase).
• Maybe add the usafe signatures as default for Maven and Gradle (not sure about this). This would help for new users, too (you can just enable the plugin and it will work asap).
• Use minimum Java 6 & merge the old jdk1.5 unsafe signatures into 1.6, this makes Gradle development easier (because you can use the new plugin infrastructure).

What do you think?

[uschindler]

FYI: PMD says in https://docs.gradle.org/current/userguide/pmd_plugin.html: "The plugin adds a number of tasks to the project that perform the quality checks. You can execute the checks by running gradle check."

[dweiss]

Hmm... Maven's validate is executed before classes are compiled, Uwe -- this means you'd be verifying last run's output. Does it make sense?

[uschindler]

Maybe I mixed up the name. I mean the phase after test. I think it's "verify". Both just start with "v".

[dweiss]

You mean 'verify'. I personally think the way it was bound (process-classes) makes a lot of sense -- an early warning signal rather than delayed check.