Support use of @JsonValue on enums for CRD generation

[bbende]

Is your enhancement related to a problem? Please describe

I have a Java enum that is generated from an Open API spec, and the generated enum uses @JsonValue on a getter to indicate the value to use for serialization. It also generates a static fromValue method with @JsonCreator.

Example:

@JsonValue
public String getValue() {
    return this.value;
}

public String toString() {
    return String.valueOf(this.value);
}

    @JsonCreator
    public static MyEnum fromValue(String value) {
        MyEnum[] var1 = values();
        int var2 = var1.length;

        for(int var3 = 0; var3 < var2; ++var3) {
            MyEnum b = var1[var3];
            if (b.value.equals(value)) {
                return b;
            }
        }

        throw new IllegalArgumentException("Unexpected value '" + value + "'");
    }

I want to use this field in a custom resource that generates the CRD from the Java classes, but the generated CRD is not using the values from the method with @JsonValue, so the enum items have all the values from the name() method like VALUE_A , VALUE_B.

I assume this is because this code here only looks for @JsonProperty:

https://github.com/fabric8io/kubernetes-client/blob/main/crd-generator/api/src/main/java/io/fabric8/crd/generator/AbstractJsonSchema.java#L114

Describe the solution you'd like

I would like to see if it is possible to also consider @JsonValue in the code linked above that processes enumerations and looks for an alternate value to use for the enum value.

Describe alternatives you've considered

No response

Additional context

No response

[bbende]

@andreaTP created this new issue based on the discussion here:

#5324 (comment)

[shawkins]

@andreaTP @bbende this should already be supported by the v2 generator.

[bbende]

@shawkins thanks for the quick reply! Sorry if this a silly question, but how do you specify the version of the generator?

I see there is a separate maven module for api-v2, is it a matter of swapping out dependencies such that you depend on crd-generator-apt but exclude the normal crd-generator-api dependency, and bring in crd-generator-api-v2 ?

I'm doing this through the Quarkus framework if that means anything.

[shawkins]

You'd have to check with the JOSDK folks, but I don't think they have release yet that aligns to the v2 generator.

[bbende]

Ah ok thank you, lets say taking JOSDK out of the picture...

A project with:

<dependency>
      <groupId>io.fabric8</groupId>
      <artifactId>crd-generator-api-v2</artifactId>
  </dependency>
  <dependency>
      <groupId>io.fabric8</groupId>
      <artifactId>crd-generator-apt</artifactId>
      <exclusions>
          <exclusion>
              <groupId>io.fabric8</groupId>
              <artifactId>crd-generator-api</artifactId>
          </exclusion>
      </exclusions>
  </dependency>

Using version 6.13.1.

Running mvn clean install produces:

[ERROR] Bad service configuration file, or exception thrown while constructing Processor object: javax.annotation.processing.Processor: io.fabric8.crd.generator.apt.CustomResourceAnnotationProcessor Unable to get public no-arg constructor

Java 21

[baloo42]

Your example won't work regardless of the java version, because the annotation processor in crd-generator-apt is not capable of using the new api-v2. The new implementation is based on reflection which can't be used in annotation processors.

If you need api-v2 now (with 6.13.x), I would recommend to backport the new CRD-Generator maven plugin. It has been designed to work with api-v2 from the beginning. I have done something similar last week and it worked out of the box.

As far as I know there is no official backport planned. But I think we should talk about it. Non-Quarkus users are otherwise not able to use api-v2 with v6. (For Quarkus, see quarkiverse/quarkus-operator-sdk#927)