Build: Fix repos.mavenLocal casing

[rjernst]

The sysprop repos.mavenLocal may be used to add the local .m2 maven
repository for testing snapshots of locally build dependencies.
Unfortunately this has to be checked in two different places (they cannot
be shared, due to buildSrc being built essentially as a separate
project), and the casing of the string sysprop lookups did not align.
This commit fixes BuildPlugin's checking of repos.mavenLocal to use the
correct casing (camelCase, to match the gradle dsl element).

[jasontedor]

LGTM.

[elasticmachine]

Pinging @elastic/es-core-infra

[uschindler]

Thanks @rjernst, I will check this with a snapshot build of forbiddenapis. It looks like the reason for the problem is the spelling difference. If I had passed both sysprops, it may have worked, right?

It would be good to also have a documentation of the repos.mavenLocal sysprop somewhere.

[uschindler]

Hi,
I can confirm, if I build forbiddenapis from master branch locally and change the version in the Elasticsearch build to "2.6-SNAPSHOT", it seems to work as expected:

• Without the sysprop, it complains that it does not find the artifact, which is expected.
• With -Drepos.mavenLocal=true it passes.

Here is my test setup:

$ git diff
diff --git a/buildSrc/build.gradle b/buildSrc/build.gradle
index 5256968..f6d5fc6 100644
--- a/buildSrc/build.gradle
+++ b/buildSrc/build.gradle
@@ -94,7 +94,7 @@ dependencies {
   compile 'com.netflix.nebula:gradle-info-plugin:3.0.3'
   compile 'org.eclipse.jgit:org.eclipse.jgit:3.2.0.201312181205-r'
   compile 'com.perforce:p4java:2012.3.551082' // THIS IS SUPPOSED TO BE OPTIONAL IN THE FUTURE....
-  compile 'de.thetaphi:forbiddenapis:2.5'
+  compile 'de.thetaphi:forbiddenapis:2.6-SNAPSHOT'
   compile 'org.apache.rat:apache-rat:0.11'
   compile "org.elasticsearch:jna:4.5.1"
 }

$ gradle -Drepos.mavenLocal=true forbiddenApis --info
[...]
> Task :server:forbiddenApisMain
Task ':server:forbiddenApisMain' is not up-to-date because:
  Task ':server:forbiddenApisMain' class path has changed from a16d2e2b06870b3cff5e2e1083327c54 to 6e48c596756fdd8209fa02252c54e800.
Reading bundled API signatures: jdk-unsafe-1.8
Reading bundled API signatures: jdk-deprecated-1.8
Reading bundled API signatures: jdk-non-portable
Reading bundled API signatures: jdk-system-out
Reading API signatures: jar:file:/C:/Users/Uwe%20Schindler/.gradle/caches/jars-3/792b7675e4222f7d952210d110ec2a75/buildSrc-7.0.0-alpha1-SNAPSHOT.jar!/forbidden/jdk-signatures.txt
Reading API signatures: jar:file:/C:/Users/Uwe%20Schindler/.gradle/caches/jars-3/792b7675e4222f7d952210d110ec2a75/buildSrc-7.0.0-alpha1-SNAPSHOT.jar!/forbidden/es-all-signatures.txt
Reading API signatures: jar:file:/C:/Users/Uwe%20Schindler/.gradle/caches/jars-3/792b7675e4222f7d952210d110ec2a75/buildSrc-7.0.0-alpha1-SNAPSHOT.jar!/forbidden/es-server-signatures.txt
Loading classes to check...
Scanning classes for violations...
Scanned 5538 class file(s) for forbidden API invocations (in 8.61s), 0 error(s).

:server:forbiddenApisMain (Thread[Task worker for ':' Thread 3,5,main]) completed. Took 9.287 secs.
:server:compileTestJava (Thread[Task worker for ':' Thread 3,5,main]) started.
[...]

Thanks, this makes testing releases of forbiddenapis before pushing the artifacts to Maven Central much easier (this would have prevented the 2.4 regression last year).

[uschindler]

A bit unrelated: When looking at the tasks in "server" module, I did not find a "forbiddenApisJava9" task, but a "checkStyleJava9" one. I have no idea why it's not setup automatically, because the plugin automatically creates a task for every sourceSet.

I think the reason for this is that the build plugin is loaded before the sourceSets are defined, so it does not see the source sets at that time. I am digging into this. A current workaround is to define the Java 9 sourceSet before the apply plugin. Then it runs forbiddenapis, but it complains about missing signatures in classpath (because Java9 sourceset has no dependencies, so it won't find stuff).

[rjernst]

Thanks for the further investigation. Is there an issue in forbiddenapis we can follow?

I don't remember how forbiddenapis finds the source sets now, but normally one would use the all method of DomainObjectCollection to run code for each object within a collection like sourceSets. It looks like that should work from pure java (an Action instead of a groovy Closure).

[uschindler]

I will open the issue now. I already solved the problem, was a bug on my side (lack of knowledge)! Instead of using forEach to iterate over all sourceSets, you have to use all which takes a closure - as you said: https://docs.gradle.org/current/javadoc/org/gradle/api/DomainObjectCollection.html#all-groovy.lang.Closure-

I will open a separate issue in Elasticsearch and also add the forbidden issue there.

[uschindler]

Here is the issue: policeman-tools/forbidden-apis#138

[uschindler]

Here is the ES issue: #29292