We've seen this a few times when building locally. The build fails like this:
> Task :spring-boot-project:spring-boot-docs:asciidoctor
Feb 22, 2021 9:50:24 AM asciidoctor
WARNING: Configuration property 'management.endpoint.jolokia.enabled' not found.
Exception in thread "main" org.asciidoctor.gradle.remote.AsciidoctorRemoteExecutionException: ERROR: The following messages from AsciidoctorJ are treated as errors:
Configuration property 'management.endpoint.jolokia.enabled' not found.
at org.asciidoctor.gradle.remote.ExecutorBase.failOnWarnings(ExecutorBase.groovy:223)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:101)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1217)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1041)
at org.codehaus.groovy.runtime.InvokerHelper.invokePogoMethod(InvokerHelper.java:1011)
at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:994)
at org.codehaus.groovy.runtime.InvokerHelper.invokeMethodSafe(InvokerHelper.java:97)
at org.asciidoctor.gradle.remote.AsciidoctorJavaExec$_run_closure3.doCall(AsciidoctorJavaExec.groovy:74)
at org.asciidoctor.gradle.remote.AsciidoctorJavaExec$_run_closure3.call(AsciidoctorJavaExec.groovy)
at org.codehaus.groovy.runtime.DefaultGroovyMethods.each(DefaultGroovyMethods.java:2330)
at org.codehaus.groovy.runtime.DefaultGroovyMethods.each(DefaultGroovyMethods.java:2315)
at org.codehaus.groovy.runtime.DefaultGroovyMethods.each(DefaultGroovyMethods.java:2356)
at org.asciidoctor.gradle.remote.AsciidoctorJavaExec.run(AsciidoctorJavaExec.groovy:67)
at org.asciidoctor.gradle.remote.AsciidoctorJavaExec.main(AsciidoctorJavaExec.groovy:49)
Our current theory is that it's a bug in the annotation processor when it's being run incrementally. In this case, we can see that Asciidoctor ran at 9:50:24. Looking at the file system, the JSON file was written at 09:49:
$ ls -al spring-boot-project/spring-boot-actuator-autoconfigure/build/classes/java/main/META-INF/spring-configuration-metadata.json
-rw-r--r-- 1 awilkinson staff 87298 22 Feb 09:49 spring-boot-project/spring-boot-actuator-autoconfigure/build/classes/java/main/META-INF/spring-configuration-metadata.json
The build scan shows that spring-boot-actuator-autoconfigure:compileJava ran due to the following changes:
Input property 'classpath' file spring-boot-project/spring-boot-autoconfigure/build/classes/java/main/org/springframework/boot/autoconfigure/jdbc/DataSourceInitialization.class has been removed.
Input property 'classpath' file spring-boot-project/spring-boot-autoconfigure/build/classes/java/main/org/springframework/boot/autoconfigure/jdbc/DataSourceInitializationConfiguration$BeforeJpaDataSourceInitializationConfiguration.class has been added.
Input property 'classpath' file spring-boot-project/spring-boot-autoconfigure/build/classes/java/main/org/springframework/boot/autoconfigure/jdbc/DataSourceInitializationConfiguration$BeforeJpaDataSourceInitializationConfiguration.class has been removed.
The metadata contains the management.endpoint.jolokia group:
{
"name": "management.endpoint.jolokia",
"type": "org.springframework.boot.actuate.autoconfigure.jolokia.JolokiaProperties",
"sourceType": "org.springframework.boot.actuate.autoconfigure.jolokia.JolokiaProperties"
},
It also contains the management.endpoint.jolokia.config property. Note that the group is as a result of processing the @ConfigurationProperties class. When the .enabled property is present, there's another management.endpoint.jolokia group:
{
"name": "management.endpoint.jolokia",
"type": "org.springframework.boot.actuate.autoconfigure.jolokia.JolokiaEndpoint",
"sourceType": "org.springframework.boot.actuate.autoconfigure.jolokia.JolokiaEndpoint"
},
It appears to be behaving as if the @Endpoint annotation isn't on the classpath, or the @Endpoint-annotated classes aren't in the RoundEnvironment.
Comment From: wilkinsona
Unfortunately, stashing the changes, building, popping the changes and then building again does not reproduce the problem and management.endpoint.jolokia.enabled is present in the generated JSON.
Comment From: wilkinsona
If we get into a situation where we can reproduce this, the annotation processor can be debugged with the following configuration in spring-boot-actuator-autoconfigure:
compileJava {
options.fork = true
options.forkOptions.jvmArgs += [ '-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=8000' ]
}
I don't know if this will disable incremental compilation which, if our theory is correct, would cause the problem to disappear.
Comment From: dreis2211
@wilkinsona I might be missing something but in your initial message you refer to spring-boot-actuator-autoconfigure while the output is actually from spring-boot-autoconfigure
The build scan shows that spring-boot-actuator-autoconfigure:compileJava ran due to the following changes:
Input property 'classpath' file spring-boot-project/spring-boot-autoconfigure/build/classes/java/main/org/springframework/boot/autoconfigure/jdbc/DataSourceInitialization.class has been removed.
Input property 'classpath' file spring-boot-project/spring-boot-autoconfigure/build/classes/java/main/org/springframework/boot/autoconfigure/jdbc/DataSourceInitializationConfiguration$BeforeJpaDataSourceInitializationConfiguration.class has been added.
Input property 'classpath' file spring-boot-project/spring-boot-autoconfigure/build/classes/java/main/org/springframework/boot/autoconfigure/jdbc/DataSourceInitializationConfiguration$BeforeJpaDataSourceInitializationConfiguration.class has been removed.
Comment From: wilkinsona
Thanks for taking a look, @dreis2211. The output is from spring-boot-actuator-autoconfigure but it is referring to changes that I made in spring-boot-autoconfigure. The changes have affected the classpath property of the spring-boot-actuator-autoconfigure:compileJava task. It's an input so Gradle correctly detected that the task needs to run. If you're interested, here's the task in its build scan so you can see things with all the surrounding context.
Comment From: dreis2211
Thanks, I just wanted to make sure we're not chasing ghosts here, but the build scan makes it indeed more obvious.
Comment From: wilkinsona
This happened again and I was able to reproduce the problem repeatedly by stashing, building, popping, and building again. I then configured compileJava so I could debug the annotation processor and the problem didn't appear. It may be coincidence, but it would appear that changing the compiler's arguments disables incremental compilation. I think we're going to have to add some diagnostics to the annotation processor to get to bottom of this.
Comment From: wilkinsona
I think this is much simpler than we'd been thinking. JolokiaEndpoint is a @ServletEndpoint yet the annotation processor only claims support for @Endpoint. When Gradle is compiling incrementally it doesn't include JolokiaEndpoint in the RoundEnvironment as it isn't annotated with an annotation that the processor claims to support. We need to add @ServletEndpoint to the supported types declared by ConfigurationMetadataAnnotationProcessor.
Comment From: wilkinsona
It's not just @ServletEndpoint. @ControllerEndpoint, @RestControllerEndpoint, and @WebEndpoint will have the same problem.
Comment From: dreis2211
I wonder if @Inherited on Endpoint would work instead of teaching the annotation processor every single one of them, @wilkinsona
Comment From: wilkinsona
Unfortunately not. @Inherited doesn't have any effect here. We either need to list all the annotation types that we want to be considered or we can use *. The latter is cautioned against in the annotation processor javadoc for performance reasons so the former is probably the best that we can do.
Comment From: wilkinsona
2.3.x doesn't have this problem as it uses *.