Refactor ClientMethod to Support Immutable Builders and Enhance Polling & Paging Metadata#7015

Merged

anuchandy merged 44 commits intomicrosoft:mainfrom

anuchandy:immutable-client-method

May 9, 2025

Commits on May 7, 2025

enable newBuilder for the ClientMethod
anuchandy
committed
Adding JavaDocs, and reuse ProxyMethod::hasParameterOfType in ProxyMethodMapper
anuchandy
committed
enable immutability in ClientMethodMapper - phase1
anuchandy
committed
enable immutability in ClientMethodMapper - phase2
anuchandy
committed
include polling-details in the shared lroBaseMethod
anuchandy
committed
enable immutability in ClientMethodMapper - phase3
anuchandy
committed
enable immutability in ClientMethodMapper - phase4
anuchandy
committed
enable immutability in ClientMethodMapper - phase5
anuchandy
committed
enable immutability in ClientMethodMapper - phase6
anuchandy
committed
enable immutability in ClientMethodMapper - phase7
anuchandy
committed
enable immutability in ClientMethodMapper - phase8
anuchandy
committed
enable immutability in ClientMethodMapper - phase9
anuchandy
committed
enable immutability in ClientMethodMapper - phase10
anuchandy
committed
Revert "enable immutability in ClientMethodMapper - phase10"
anuchandy
committed
Split lro begin
anuchandy
committed
enable immutability in ClientMethodMapper - phase11
anuchandy
committed
enable immutability in ClientMethodMapper - phase11
anuchandy
committed
enable immutability in ClientMethodMapper - phase12
anuchandy
committed
java-doc to PagingMetadata, make continuation-token segement list immutable, add toContextParameter method
anuchandy
committed
revert use of toImmutableList in PagingMetadata
anuchandy
committed
Renaming JavaSettings::PollingDetails to PollingSettings (so the name indicates its something user provided and can be distinguished from polling details extracted from Operation metadata)
anuchandy
committed
move lro skip cases as a check within lro handling block
anuchandy
committed
simplify some part of lro meta resolution
anuchandy
committed
simplify lro meta strategy resolution
anuchandy
committed
use consistent naming for poll intermediate-response/result and final response/result
anuchandy
committed
Introducing PollingMetadata class LRO operations (similar to PagingMetadata for pagable oepration
anuchandy
committed
ensure PollingSettings property names are consistent with MethodPollingDetails's
anuchandy
committed
additional javadoc for PollingMetadata
anuchandy
committed
attempt lro condition simplification
anuchandy
committed
initial attempt to use PollingMetadata
anuchandy
committed
polishing use of PollingMetadata
anuchandy
committed
Adding updated lro generated code since the method ordering changed
anuchandy
committed
Define CreateClientMethodArgs to pass immutable args across client method creator functions
anuchandy
committed
move lro-with-response logic to new method createLroWithResponseMethods(..) and use it
anuchandy
committed
simplifying createLroWithResponseMethods by moving fluent specifics to a seperate function
anuchandy
committed
simplifying createLroWithResponseMethods to take isSync param (like other similar methods)
anuchandy
committed
java doc, naming consistency
anuchandy
committed
make lro fluent conditional flow more explicit (will help when we do work to extract fluent out of common client-method-mapper
anuchandy
committed
Ensure FluentClientMethodMapper method creation follow the same coding pattern as ClientMethodMapper, naming consistency for all create-client-methods functions
anuchandy
committed
consolidate javaDoc setters, aligin paramaters ordering across create-client-method functions
anuchandy
committed
Updating based on first round of code review discussion
anuchandy
committed
consistent code pattern for method visibility
anuchandy
committed
incorporating review feedback (simplify createFluentLroWithResponseSyncClientMethods, JavaDoc, var-names)
anuchandy
committed
rebase with upstream/merging corev2 changes
anuchandy
committed