The mapper processor fails due to missing dependency to slf4j, which was removed in JAVA-2800. Output of "mvn clean compile -X":
Our temporary fix was to add the slf4j dependency to the <annotationProcessorPaths>:
Not sure whteher this problem also has to do with the fact that we have @Mapper and @Dao in the same class? For example:
Thank you for your help.
Sorry about that.
The error happens because the DAO is a nested class, the fact that the outer class is also annotated does not play a role. Your temporary fix is right, you can also add slf4j-nop if you want to avoid the warning message about missing bindings.
I will revisit this for the next release. It's OK if the processor code accidentally issues a few logs that will be ignored, but they shouldn't make the compilation fail.
The error happens because the DAO is a nested class
Just for posterity: I was completely wrong there. The error happens whether the DAO interface is nested or not. It comes from the check introduced in JAVA-2298, which is done for @Query or any annotation that has custom clauses.
This is a real conundrum. The hard part is that the annotation processor can be used in two different ways:
as a regular dependency, and the compiler will look for processors in the normal classpath.
We need a solution that works in both cases.
If the processor brings its own SLF4J binding, that will prevent the "Defaulting to no-operation (NOP)" warning in situation 1. But it will collide with the user's own binding in situation 2, which leads to a different warning: "Class path contains multiple SLF4J bindings".
I think the most pragmatic approach would be to simply revert JAVA-2800, and let the "Defaulting to no-operation (NOP)" warning surface. It's not a big deal, and it's an accurate description of the situation after all: we do want to default to NOP.
If users really want to get rid of the warning, they can add slf4j-nop manually to their processor path. We can explain that in the manual.