test: add Kotlin verification smoke test

[hej090224]

Closes #2967

What this does

Adds a Kotlin-based smoke test to operator-framework-core verifying that JOSDK behaves correctly when a DependentResource is implemented in Kotlin.

Kotlin has no concept of checked vs. unchecked exceptions, so Kotlin code can throw a plain Exception from an overridden method (e.g. DependentResource#reconcile) without declaring it — even though the Java-declared method signature doesn't include throws Exception. Before #2965, NodeExecutor only caught RuntimeException, so such an exception thrown from Kotlin would silently bypass the workflow's error handling and not trigger a retry.

The new test (KotlinCheckedExceptionDependentResourceTest.kt):

• Defines a Kotlin DependentResource whose reconcile throws a custom checked Exception.
• Runs it through the real Workflow/WorkflowReconcileExecutor/NodeExecutor (no mocked cluster needed).
• Asserts the exception is captured in WorkflowReconcileResult#getErroredDependents() and that throwAggregateExceptionIfErrorsPresent() throws AggregatedOperatorException, confirming a retry would be triggered.

I verified this test actually exercises the fix: temporarily reverting NodeExecutor's catch (Exception e) back to catch (RuntimeException e) (the pre-#2965 behavior) makes the test fail, since the checked exception is then silently swallowed and getErroredDependents() stays empty.

Build changes

• Adds kotlin-maven-plugin (test scope only, 2.4.10) to operator-framework-core/pom.xml, compiling sources under src/test/kotlin. No other module is affected, and no Kotlin dependency is added to the main/runtime classpath.

Relation to #2965

#2965 fixed NodeExecutor, AbstractWorkflowExecutor, and PollingEventSource to catch Exception instead of RuntimeException (with // Exception is required because of Kotlin comments already in place), and opened #2967 as a follow-up to add tests validating this behavior with actual Kotlin code. I also grepped the codebase for any remaining catch (RuntimeException in main sources and found none left to fix.

I scoped this PR to a unit-test-level smoke test (no real Kubernetes cluster required) so it's fast and fully verifiable in CI; a full Kotlin-based *IT.java-style integration test against LocallyRunOperatorExtension could be a good follow-up if maintainers want broader coverage.

Test plan

• ./mvnw -pl operator-framework-core -am test — 646 tests pass
• Verified the new test fails against the pre-fix: handle all exceptions to support Kotlin #2965 catch (RuntimeException) behavior, and passes against current catch (Exception) behavior

[Copilot]

Pull request overview

Adds Kotlin-based test coverage to ensure the workflow executor correctly captures non-RuntimeException failures thrown from Kotlin-implemented DependentResources, preventing silent bypass of retry/error aggregation logic.

Changes:

• Introduces a Kotlin smoke test that throws a checked Exception from DependentResource.reconcile and asserts it is surfaced via erroredDependents and aggregated exceptions.
• Updates operator-framework-core build to compile src/test/kotlin via kotlin-maven-plugin and adds Kotlin stdlib as a test-scoped dependency.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
operator-framework-core/src/test/kotlin/io/javaoperatorsdk/operator/processing/dependent/workflow/KotlinCheckedExceptionDependentResourceTest.kt	Adds Kotlin smoke test validating workflow error capture/aggregation for checked exceptions thrown from Kotlin dependents
operator-framework-core/pom.xml	Adds Kotlin test compilation support and Kotlin stdlib dependency (test scope) to enable the new Kotlin test

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

[csviri]

@hej090224 thank you for the PR, there is a syntaxt error.

But I was wondering if this is enough to validate this. Would be better IMO to add a sample, a minimalist operator kontlin, and the related E2E test as for other samples, that tests the whole lifecycle. Would you mind to implement this issue that way?

The controller could just apply a config map, copy a String value from custom resource spec. But that would show also that deserialization works from fabric8 client, and if the whole runtime is working.