CRD-Generator Maven Plugin Improvements

[baloo42]

After receiving some feedback on the new CRD-Generator Maven Plugin I want to start a discussion what we can improve in terms of usability and functionality.

Some background details about the current implementation can be found here:

https://github.com/baloo42/crd-generator-v2-docs/blob/main/crd-generator-maven-plugin.md

The most important facts to know:

• There is the classpath and the scan-scope to consider.
• The scan-scope must be always part of the classpath
  because CustomResource classes must be loaded so that the CRD-Generator can process them.
• But not all classpath elements must be in the scan-scope:
  Only the intended CustomResource classes must be in the scan-scope, so that they can be found.
• Scanning is slow compared to class loading:
  If no jandex index can be found in a scan element (directory, Jar file), then the collector will create first an in-memory index for the whole element. Then the actual lookup for CustomResource classes happens.
  Loading a few classes from a classpath which contains many elements is compared to the index-creation fast.
• Because of this, we have avoided to default to settings where the scan-scope equals to the classpath. It would be otherwise a bottleneck which slows down bigger projects by default.

Ideas / Thoughts

Phase

At the moment, the phase of the CRD-Generator Maven Plugin defaults to process-classes.
But it's easy to forget about this in some cases where this is important. Is there a phase available which fits better as default?

https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference

Constraints:

• The CRD-Generator Maven Plugin expects compiled classes, this means it must be executed after the compile phase.
• If the CRD-Generator should consider classes from test sources, then it must be executed after test-compile.
• To support tests, which are using the emitted CRDs and running int the test phase, the CRD-Generator Maven plugin must be executed before test phase.

classpath (ClasspathType)

https://github.com/fabric8io/kubernetes-client/blob/main/crd-generator/maven-plugin/src/main/java/io/fabric8/crd/generator/maven/plugin/ClasspathType.java#L24

Additional classpath "types" can be added easy and I'm open for suggestions. For example a new ClasspathType.RUNTIME_AND_TEST like suggested in #6683.

Constraints:

• Maven offers access to a few sets of classpaths. Those inherit often e.g. the project classes on their own. This means we have to implement a more sophisticated way to get the classpath elements we want if we want to extend the list of types with other combinations.

We can also consider allowing the user to fully customize the classpath e.g. with a new ClasspathType.NONE and additionalClasspathElements like the Maven Surefire Plugin does.

scan-scope (classesToScan, dependenciesToScan)

classesToScan defaults at the moment to ${project.build.outputDirectory} which is probably most expected.

The intention of choosing here a single value property is to make it easily switchable to something else e.g. to ${project.build.testOutputDirectory}.

Dependencies can be added to the scan-scope by using dependenciesToScan (see CRD-Generator Maven Plugin Readme - Scan a dependency for Custom Resource classes).

But at the moment a user has always to consider the constraints from the beginning and adjust the classpath in some cases.

Usability Shortcuts

At the moment the CRD-Generator Maven Plugin doesn't try to fix the setup of a user automatically. It also doesn't offer usability shortcuts beyond sane defaults. The current implementation uses classpath elements and scan-scope targets isolated from each other.

Despite the maven plugin, the CRD-Generator CLI has already implemented such a shortcut:

https://github.com/fabric8io/kubernetes-client/blob/main/crd-generator/cli/src/main/java/io/fabric8/crd/generator/cli/CRDGeneratorCLI.java#L293

What shortcuts can we implement?

• Add scan-scope automatically to classpath (like the CLI does)
• Add classpath automatically to scan-scope (suggested in CRD Generator maven plugin fails to detect CustomResources that are located in test sources #6683)

But more important, should we implement such a shortcut?