Double generation from CRD to Java and back to CRD

Describe the bug

I have the use case that I need to both generate CDR from Java, as well as generating Java from CDR. So I have both the annotation processor and maven plugin configured.

From what I can see, the maven plugin runs first and it generates Java code, and then the annotation processor kicks in, which totally makes sense because before compilation code needs to be generated.

The result is a roundtrip happens for the CDR and I get the generated one under /META-INF/fabric8 along with the original one in a different place. This is not a real problem, but could be confusing.

Fabric8 Kubernetes Client version

6.0.0

Steps to reproduce

Configure annotation processor

    <dependency>
      <groupId>io.fabric8</groupId>
      <artifactId>crd-generator-apt</artifactId>
      <scope>provided</scope>
    </dependency>

Configure maven plugin

      <plugin>
        <groupId>io.fabric8</groupId>
        <artifactId>java-generator-maven-plugin</artifactId>
        <executions>
          <execution>
            <goals>
              <goal>generate</goal>
            </goals>
          </execution>
        </executions>
        <configuration>
          <source>src/main/resources/kubernetes/crds</source>
        </configuration>
      </plugin>

Compile

mvn compile

Expected behavior

Maybe there is a way to configure the annotation processor to skip generated code that I’m not aware of. The expected behaviour is not to generate CDR form generated code.

Runtime

Kubernetes (vanilla)

Kubernetes API Server version

1.24.2@latest

Environment

macOS

Fabric8 Kubernetes Client Logs

NA

Additional context

For a reason I have to use 5.12.3 annotation processor, but 6.0.0 maven plugin. Not sure whether that matters.

[honnix]

I guess, better to have some identity so it won’t skip other generated files, @Generated(value="io.facric8....").

[andreaTP]

I checked and there is, at the moment, no easy way to disable the CRD generator on a particular CRD and the separation @manusa suggested is the only viable option.

That said I’m all in for adding javax.annotation.processing.Generated which is indeed good practice, thanks for the suggestion @honnix 👍 .

The only suggestion(if it’s not me going to implement it) is to make it configurable (even a hidden configuration is fine) to not prevent testing the two generators as we are doing in the it tests.