Add @TemporalOperation annotation for Nexus operations

[Quinn-With-Two-Ns]

What was changed

Introduces @TemporalOperation, a method-level annotation that declares a Temporal-backed Nexus operation directly on a @ServiceImpl class. The framework wraps the annotated method as the start handler with default cancel behavior, removing the boilerplate of a separate TemporalOperationHandler for the common workflow-run case. @OperationImpl is still supported for custom cancel or handler composition, and both annotations can coexist on the same service (but not the same method).

Why?

Make it easier to define Nexus Operation Handlers by having less boilerplate between the interface and the implementation

Checklist

1. Closes

2. How was this tested:

3. Any docs updates needed?

Note requires nexus-rpc/sdk-java#46 to be merged

---

Note

Medium Risk
Changes Nexus service registration and handler dispatch for all workers; mis-annotated services fail at registration, but runtime behavior for existing @OperationImpl paths should be unchanged.

Overview
Adds @TemporalOperation, a method-level annotation on @ServiceImpl classes so the annotated method is the Nexus start handler (wrapped in TemporalOperationHandler with default cancel behavior) instead of returning an OperationHandler via @OperationImpl + TemporalOperationHandler.create.

TemporalOperationProcessor plugs a MethodExtension into ServiceImplInstance.fromInstance to scan @TemporalOperation methods, validate signatures (TemporalOperationStartContext, TemporalNexusClient, input) and TemporalOperationResult<R>, and bind them with MethodHandle. Nexus worker registration, Spring Boot worker setup, and test utilities now call TemporalOperationProcessor.process instead of ServiceImplInstance.fromInstance alone.

TemporalOperationHandler.create is removed; docs steer common cases to @TemporalOperation and custom cancel to subclassing TemporalOperationHandler with @OperationImpl. Existing generic-handler tests are migrated to @TemporalOperation; new unit and E2E tests (Java and Kotlin) cover validation and mixed @TemporalOperation / @OperationImpl services. Build adds includeBuild('../nexus/nexus-sdk-java') for the nexusrpc MethodExtension API.

^{Reviewed by Cursor Bugbot for commit 240ac38. Bugbot is set up for automated code reviews on this repo. Configure here.}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 240ac3836c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Remove the hard-coded sibling composite build

In a normal checkout that does not also have ../nexus/nexus-sdk-java, Gradle evaluates this settings file before any task and the build is blocked by the missing included build; Gradle documents includeBuild here as adding another build to the composite, while the CLI --include-build is the optional one-off form. Please don't commit a machine-local composite path; use the published dependency or make local Nexus development opt-in so ./gradlew test works from a clean sdk-java checkout.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Preserve the existing factory method

This change deletes the public TemporalOperationHandler.create(...) API, but existing users implementing @OperationImpl with the documented factory will fail to compile after upgrading even though the new annotation is only additive. The repository guidance says to avoid public API signature changes; keeping this factory as a compatibility wrapper around the constructor lets existing custom handlers continue to build while still documenting @TemporalOperation as the preferred path.

Useful? React with 👍 / 👎.