https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
t
Looks like a bug. 
compileClasspath
should resolve the 
api
variant, but 
annotationProcessor
should resolve the 
runtime
variant. If that's not the case, then it's a bug in Gradle.
v
Should be the case, yes:
Copy code
jvmPluginServices.configureAsRuntimeClasspath(annotationProcessorConfiguration);
I'd say an MCVE would be helpful.
t
Could it failed due to the fact, that 
project-a
is defined within implementation configuration in 
project-b
even though it should be within api (because of project-a's classes are used with public visibility within project-b)? I know, it's a bug on our side.
v
A dependency should be in 
api
if you use its types in the public API like method parameters, return types, superclasses, ... If you just use the classes in private methods or method bodies, 
implementation
is the right choice. As 
annotationProcessor
should be pulling in the runtime classpath, it should also get the 
implementation
dependencies. So if 
b
has 
implementation
dependency on 
a
and you only add 
b
to 
annotationProcessor
of 
c
, then the classes of 
a
should automatically be present even without an explicit dependency on 
a
from `c`'s 
annotationProcessor
.
t
Yop, I know about the API like methods and how to distinguish api and implementation configurations. I just didn't expect we have a bug there. Which I have just discovered. So it should work, thanks. Here is the example: https://github.com/little-fish/mcve-gradle-annotation-processor
v
Copy code
14:58:41: Executing 'classes'...

> Task :project-a:compileJava
> Task :project-a:processResources NO-SOURCE
> Task :project-a:classes
> Task :project-a:jar
> Task :project-b:compileJava
> Task :project-c:compileJava
> Task :project-c:processResources NO-SOURCE
> Task :project-c:classes

BUILD SUCCESSFUL in 25s
4 actionable tasks: 4 executed
14:59:12: Execution finished 'classes'.
Only thing I changed to your commited state is that I replace the bad 
-all
by the good 
-bin
🙂
t
Wait what? What's wrong with -all? -bin fails on my machine as well. (Btw I am using Java 8)
v
-all
is helpful in exactly one situation. If you use Groovy DSL build scripts and only while editing the build scripts. In all other cases, it is just a waste of time, bandwidth, and disk space for everyone and everything just executing the build
Hm, interesting, I executed with Java 11 when it worked. With Java 8 I get the same error.
t
I thought that its just one time download. In such a case I rather have everything ready for build script editing ,)
t
Correct me if I'm wrong but this has nothing to do with 
annotationProcessor
then? In the MCVE, 
annotationProcessor
only includes 
:project-a
, not 
:project-b
-that-has-a-dependency-on-
:project-a
. This looks more like something to do with either the 
spring-boot-configuration-processor
and/or JDK annotation processing, and would likely work the same with Gradle out of the equation.
Copy code
Caused by: java.lang.IllegalStateException: Error processing configuration meta-data on foo.bar.c.Bla
        at org.springframework.boot.configurationprocessor.ConfigurationMetadataAnnotationProcessor.processElement(ConfigurationMetadataAnnotationProcessor.java:218)
        at org.springframework.boot.configurationprocessor.ConfigurationMetadataAnnotationProcessor.process(ConfigurationMetadataAnnotationProcessor.java:172)
v
It is a one-time download if it is already there. If you for example build on an ephemeral build agent or in a docker image, it will always be redownloaded. And even if it is just downloaded once, it still wastes disk space unnecessarily
👍 1
Regarding the MCVE, I guess this is a Java compiler bug as it works with Java 11. But actually you have 
A
as annotation processor dependency and 
B
as 
api
dependency which then misses 
A
for compilation. If you add 
A
as compile dependency in 
C
where it is missing, it also works with Java 8
t
@Thomas Broyer You are correct. I fixed the dependency within the MCVE. @Vampire To be honest, I am lost between 
A
, 
B
and 
C
🙂 Can you be more specific please?
t
You are correct. I fixed the dependency within the MCVE.
Changes nothing to the problem: likely a bug in the JDK and nothing to do with Gradle; in the MCVE I don't even understand why the projects are added to the 
annotationProcessor
.
t
My initial thoughts were based on the fact that if I change `project-b`'s dependency on 
project-a
to 
api
(instead of 
implementation
), it works fine. So I tried to add the dependency directly to the 
project-c
's 
annotationProcessor
.
v
But as I said, it is not missing on the 
annotationProcessor
class path, but on the compile class path. So if you add it to `project-c`'s 
api
or 
implementation
it works even with Java 8
t
Oh, I see. Thank you guys for explanations.
12 Views
Open in Slack
PreviousNext
Powered by