quarkus-infinispan-client stops working along with mapstruct-processor

[theseeker58]

Hi, I have an application based on quarkus-infinispan-client. Everything works fine as long as I don't use Mapstruct to map data transfer object to the domain objects annotated with protostream. As soon as I configure maven-compiler-plugin with mapstruct processor

          <configuration>
            <annotationProcessorPaths>
              <path>
                <groupId>org.mapstruct</groupId>
                <artifactId>mapstruct-processor</artifactId>
                <version>${mapstruct.version}</version>
              </path>
            </annotationProcessorPaths>
          </configuration>

quarkus-infinispan-client stops generating schema from the Interface that extends SerializationContextInitializer.

No exception is thrown. It just stops working as expected.

Is it a bug?

[quarkus-bot[bot]]

/cc @karesti, @wburns

[wburns]

@theseeker58 Does it generate the schema file (target/classes/proto/generated/$schemaFileName) and the impl for the SerializationContextInitializer in the target/classes directory?

[theseeker58]

only the compiled Interface. The Impl class is no longer generated. If I remove mapstruct-processor it works fine again

Il giorno mer 7 apr 2021 alle ore 16:15 William Burns < @.***> ha scritto:

@theseeker58 https://github.com/theseeker58 Does it generate the schema file (target/classes/proto/generated/$schemaFileName) and the impl for the SerializationContextInitializer in the target/classes directory?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/quarkusio/quarkus/issues/16315#issuecomment-814950321, or unsubscribe https://github.com/notifications/unsubscribe-auth/APQ5JYZ2IY3SLCDCUZVM7V3THRSG5ANCNFSM42QTISCA .

[gsmet]

Probably better if you prepare a small reproducer for the issue.

[theseeker58]

I just pushed to github a small project to reproduce the issue https://github.com/theseeker58/code-with-quarkus.git The README.md file explains how to. In short, if you compile and execute the quarkus project you'll find that protostream stuff is correctly generated (I mean serialization context initializer and marshaller). Then uncomment mapstruct-processor in pom, follow the instructions in the README and clean, compile and execute again. You'll no longer find, in the target directory, what protostream should have generated. Thanks

[danberindei]

@theseeker58 please push the changes that make the compilation break for you. I have tried the instructions in README.md and mvn clean compile test still works.

[theseeker58]

@danberindei Compilation works fine with no errors. The problem is that org.acme.model.CatalogSchemImpl.class is no longer generated under the target dir. OBV without a real Infinispan server you won't get any exception. Try to uncomment mapstruct-processor under the configuration section of maven-compiler-plugin and you'll notice yourself

[danberindei]

I see now @theseeker58, I missed the final paragraph in README.md and expected the test to fail.

[danberindei]

@theseeker58 the problem is that you are setting the annotation processor paths explicitly in the compiler plugin:

        <configuration>
          <annotationProcessorPaths>
            <path>
              <groupId>org.mapstruct</groupId>
              <artifactId>mapstruct-processor</artifactId>
              <version>${mapstruct.version}</version>
            </path>
          </annotationProcessorPaths>
        </configuration>

Normally the compiler plugin automatically detects the annotation processors from all the jars on the classpath. But when you set annotationProcessorPaths in the maven-compiler-plugin configuration, the compiler will only look for annotation processors in the jars you specified: https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#annotationProcessorPaths

Because your explicit annotation processor paths includes the mapstruct processor but not the protostream processor, only the mapstruct processor is found and runs. If you remove the <annotationProcessorPaths> element, the compiler finds both the mapstruct and the protostream annotation processors in the classpath, and all the files are generated.

[theseeker58]

@danberindei unfortunately that explicit configuration is needed by mapstrut. Without that, mapstruct no longer generates sources from the annotated interface. Mapstruct behaviour seems to be different from protostream approach. So how to?

[danberindei]

@theseeker58 like the <annotationProcessorPaths> documentation says, "If specified, the compiler will detect annotation processors only in those classpath elements." (my emphasis)

That means you can't add one processor path explicitly and expect the compiler to automatically detect the other processors, you must add all processor paths explicitly. You can add the protostream processor path explicitly using something like this (not tested):

          <configuration>
            <annotationProcessorPaths>
              <path>
                <groupId>org.infinispan.protostream</groupId>
                <artifactId>protostream-processor</artifactId>
                <version>${protostream.version}</version>
              </path>
            </annotationProcessorPaths>
          </configuration>

[wburns]

The issue was that the annotation processor path was explicitly overridden and thus the protostream annotation processor was never utilized.

[omasseau]

The issue was that the annotation processor path was explicitly overridden and thus the protostream annotation processor was never utilized.

Would be nice to add this information in the documentation. I banged my head for hours while trying to find why my @ProtoSchema annotations were not processed ;)

[karesti]

@omasseau did you make mapstruct and protostream work together ?

[omasseau]

@omasseau did you make mapstruct and protostream work together ?

Yes either by removing annotationProcessorPaths element in pom.xml or by declaring both annotation processors in as described by danberindei ;)

[karesti]

@omasseau with @AutoProtoSchemaBuilder or @ProtoSchema ?

[omasseau]

@omasseau with @AutoProtoSchemaBuilder or @ProtoSchema ?

@karesti I've only used @ProtoSchema, so @ProtoSchema in my case ;)

[karesti]

@omasseau ok, thanks! I get an error with @ProtoSchema and not with @AutoProtoSchemaBuilder (which is the old name of the ProtoSchema). thanks ! I'm going to check if we are missing something, and I will push the documentation help. Thanks!

[karesti]

Reopening to add the documentation information