CRD Generator Annotation Issues with v6 RC1

[csviri]

Describe the bug

When tried to use version v6 R1, got an error for annotation processor that generates CRD-s:

 Compilation failure
[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

Fabric8 Kubernetes Client version

6.0.0-RC1

Steps to reproduce

Check out this build:
https://github.com/java-operator-sdk/admission-controller-framework/runs/7211447592?check_suite_focus=true

it's very simple project where a minimalist custom resource is defined.

or in Java Operator SDK:
operator-framework/java-operator-sdk#1305

Expected behavior

CRD is generated, no error.

Runtime

Build with Java 11

Kubernetes API Server version

1.22.3@latest

Environment

Linux

Fabric8 Kubernetes Client Logs

No response

Additional context

No response

[sanyarnd]

Same issue with 6.0.0

[csviri]

As a workaround, adding this dependency solves the problem:

<dependency>
    <groupId>io.fabric8</groupId>
    <artifactId>crd-generator-api</artifactId>
 </dependency>

thx @manusa and @iocanel !

[andreaTP]

@csviri would you mind to elaborate?
crd-generator-api is a transitive dependency of crd-generator-apt and, the only reason (I can think about) why a direct dependency would fix something is because of a misconfiguration of the shading. Any other ideas?

[csviri]

Maybe @iocanel could tell more. But afik that was the conclusion at the end, that is probably something with shading.

[manusa]

Issue might be caused by the version bump in maven-shade-plugin (#4020)

The generated dependency-reduced-pom.xml (same as the one in Maven Central) doesn't show dependencies for the crd-generator-api module.

I understand that providing a more detailed configuration would solve the issue:

kubernetes-client/crd-generator/apt/pom.xml

Lines 60 to 73 in 97c68b9

	<configuration>
	<shadedArtifactAttached>true</shadedArtifactAttached>
	<shadedClassifierName>processors</shadedClassifierName>
	<filters>
	<filter>
	<artifact>*:*</artifact>
	<includes>
	<include>io/fabric8/crd/generator/**</include>
	<include>META-INF/services/javax.annotation.processing.Processor</include>
	<include>META-INF/MANIFEST.MF</include>
	</includes>
	</filter>
	</filters>
	</configuration>

[manusa]

Anyone knows why was a shading configuration provided in the first place?

[andreaTP]

I can reproduce and the bump of the shading plugin is really causing this issue.

I "think" that shading was added because the crd-generator itself depends on kubernetes-model-common but the shading configuration was added in the first place (it's been there since the pom.xml was created in this repository).

Entierly removing the shading configuration fixes the problem for the java-operator-sdk codebase.

Additional note, I cannot observe any difference in the dependency-reduced-pom.xml using a different version of the shading plugin.

[iocanel]

Anyone knows why was a shading configuration provided in the first place?

The shading configuration was there originally when the generator was part of dekorate.

In dekorate we decided to optionally split annotations and processors to make things more gradle friendly (which from a certain version onwards adopts some weird restrictions related to apt).

[iocanel]

BTW, dekorate uses shading plugin version 3.0.0 and we don't have this issue.

[manusa]

BTW, dekorate uses shading plugin version 3.0.0 and we don't have this issue.

Yup, the bump is from 3.2 to 3.3, so I assume 3.0 shouldn't be affected.

Entierly removing the shading configuration fixes the problem for the java-operator-sdk codebase.

If there's no real purpose for adding shading (I can't think of any), I would remove it.

There's also shading configuration for java-generator-cli, but I think this shouldn't be necessary either (assuming that really-executable-jar-maven-plugin takes care of making the fat jar).

Additional note, I cannot observe any difference in the dependency-reduced-pom.xml using a different version of the shading plugin.

My understanding is that the deploy phase now selects/pushes the dependency reduced pom instead of the regular pom.

[andreaTP]

@manusa unfortunately the really-executable-jar-maven-plugin doesn't take care of building the uber jar.
I followed the instructions for Picocli: https://picocli.info/#_really_executable_jar

[manusa]

@manusa unfortunately the really-executable-jar-maven-plugin doesn't take care of building the uber jar. I followed the instructions for Picocli: https://picocli.info/#_really_executable_jar

👍 This means that in this case the usage of the shade plugin is justified.