Gradle cache

[mkmaier]

Apart from the https/rat stuff, this is the minimal needed change to support gradle build caching properly.
It is still necessary to enable the cache explicitly with outputs.cacheIf { true }. This is intentional, because caching will cause no warnings to be logged if there is a cache hit, which might confuse users. This is not a problem with ignoreFailures = false, since failed tasks should not be cached.

[uschindler]

Hi,
this would fix #146, but the other issue mentions that a "cacheable" task also needs to explicitly marked as "cacheable": https://docs.gradle.org/current/userguide/build_cache.html#sec:task_output_caching_details

[uschindler]

We can use cacheIf to enable caching only if ignoreFailures == false. That's easy to add to the plugin-init.groovy.

[mkmaier]

this would fix #146, but the other issue mentions that a "cacheable" task also needs to explicitly marked as "cacheable": https://docs.gradle.org/current/userguide/build_cache.html#sec:task_output_caching_details

One of @CachableTask or outputs.cacheIf { true } is enough.

We can use cacheIf to enable caching only if ignoreFailures == false. That's easy to add to the plugin-init.groovy.

My change fixes the UPTO-DATE check for the task, so now it can actually be UPTO-DATE.
Combined with your trick of declaring @OutputDirectories public FileCollection getClassesDirs(), this means that the task will always be UPTO-DATE if the respective compile task input/output is unchanged (even if that just came from cache). So what I wrote above about having to enable the cache is not correct.
Most of the time, this will have the same effect as using the cache for this task, but it's not perfect:

1. If caching is enabled manually, the compile output will probably be cached twice. This should be fixed by declaring a real output file in Allow to produce a text/xml/json/... report of the failures for better CI integration #134, anything else will be a workaround that is not much better than the current situation.
2. If failures are ignored, the check will still not run every time (even if caching is not enabled for the task), which might confuse users, but is really a matter of taste. If you want this to be fixed, then outputs.upToDateWhen { false } should be used in that case, but I'm not sure this is really worth the trouble, and it would also be better to fix this by outputting the warnings to a file.

What's your opinion on this? Do you want me to change anything?

[uschindler]

If failures are ignored, the check will still not run every time (even if caching is not enabled for the task), which might confuse users, but is really a matter of taste.

This was also the case before. Actually the uptodate check was working most of the time. Maybe it changed in one later Gradle version when @classpath was introduced.

Nevertheless I like your change. I just have to think when to include this.

One opportunity would be to release the Java 14 update in March as version 3.0, so I can also remove the old deprecated stuff, too. In that case I will add some more commits afterwards to change minimum java version and remove *-1.6 signatures files (merge them into the 1.7 ones).

Do you want me to change anything?

All fine as first step.

[uschindler]

I am working on #160, which will update to Java 7 and forbiddenapis 3.0. After this is merged, I will apply your PR.

Thanks anyways and sorry for the delay!