Currently, if you want to write a Java tool that manages Console resources (create, read, update, delete against the Kubernetes API), there's no artifact available to an external Java build. The CR classes (Console, ConsoleSpec, ConsoleStatus, and their supporting types) live inside the console-operator module and are only ever built as part of the operator itself, so anyone else who wants them has to hand-write equivalent classes or copy the source out of this repo.
That conflicts with how the rest of the StreamsHub ecosystem does things. Strimzi publishes its CRD classes as io.strimzi:api, Apicurio Registry publishes theirs as io.apicurio:apicurio-registry-operator-model, and Kroxylicious does the same with io.kroxylicious:kroxylicious-kubernetes-api. In each case it's the same shape: the fabric8-annotated CR classes get pulled out into their own small module with minimal dependencies, and that module gets published to Maven Central alongside the rest of the release.
The Console CRD classes are already a good fit for this. They don't depend on anything from the operator's runtime, no Quarkus, no operator-sdk, no reconciler code, just fabric8 model/annotation types, jakarta validation, and the sundr builder-annotations processor. Publishing them as their own artifact would let anyone building automation, CLIs, or integrations around the Console CRD just add a Maven dependency instead of vendoring source, and would bring the console in line with how Strimzi, Apicurio and Kroxylicious already handle this.
Proposed changes
- Extract the CR classes currently under
operator/src/main/java/com/github/streamshub/console/api/v1alpha1/ into a new standalone Maven module, e.g. operator-api, producing an artifact such as com.github.streamshub:console-operator-api.
- Update the
console-operator module to depend on this new module instead of containing the classes directly. No behavioural change to the operator itself.
- Add Maven Central publishing configuration (source/javadoc jars, GPG signing, the Central Publisher Portal plugin) scoped only to this new module, since the rest of the project currently disables
mvn deploy entirely on release.
- Extend the release workflow to publish this module to Maven Central as part of each release.
Open questions
- Publishing to Maven Central requires namespace verification for
com.github.streamshub on the Central Publisher Portal and a GPG signing key, both of which need to be set up once by someone with access to the streamshub GitHub org, plus corresponding CI secrets.
- This would be, AFAIK, our first published artifact and it highlights that the Group ID for the console (com.github.streamshub) should probably change to
io.streamshub. This issue is covered in the this proposal.
Currently, if you want to write a Java tool that manages Console resources (create, read, update, delete against the Kubernetes API), there's no artifact available to an external Java build. The CR classes (
Console,ConsoleSpec,ConsoleStatus, and their supporting types) live inside theconsole-operatormodule and are only ever built as part of the operator itself, so anyone else who wants them has to hand-write equivalent classes or copy the source out of this repo.That conflicts with how the rest of the StreamsHub ecosystem does things. Strimzi publishes its CRD classes as
io.strimzi:api, Apicurio Registry publishes theirs asio.apicurio:apicurio-registry-operator-model, and Kroxylicious does the same withio.kroxylicious:kroxylicious-kubernetes-api. In each case it's the same shape: the fabric8-annotated CR classes get pulled out into their own small module with minimal dependencies, and that module gets published to Maven Central alongside the rest of the release.The Console CRD classes are already a good fit for this. They don't depend on anything from the operator's runtime, no Quarkus, no operator-sdk, no reconciler code, just fabric8 model/annotation types, jakarta validation, and the sundr builder-annotations processor. Publishing them as their own artifact would let anyone building automation, CLIs, or integrations around the Console CRD just add a Maven dependency instead of vendoring source, and would bring the console in line with how Strimzi, Apicurio and Kroxylicious already handle this.
Proposed changes
operator/src/main/java/com/github/streamshub/console/api/v1alpha1/into a new standalone Maven module, e.g.operator-api, producing an artifact such ascom.github.streamshub:console-operator-api.console-operatormodule to depend on this new module instead of containing the classes directly. No behavioural change to the operator itself.mvn deployentirely on release.Open questions
com.github.streamshubon the Central Publisher Portal and a GPG signing key, both of which need to be set up once by someone with access to thestreamshubGitHub org, plus corresponding CI secrets.io.streamshub. This issue is covered in the this proposal.