edk12564 commented on PR #5744:
URL: https://github.com/apache/fineract/pull/5744#issuecomment-4202310865
> Hello @edk12564, I wasn't thinking about maintaining a separate predefined
spec. I was thinking more about a build-time step in the existing OpenAPI
generation flow. To make the idea more concrete, I was imagining something in
the existing `:fineract-provider:resolve` flow, for example a `doLast `step
that normalizes the generated spec after Swagger writes it:
>
> ```groovy
> doLast {
> def result = new
ClassForNormalization().normalize(file("${buildDir}/resources/main/static/fineract.json"),
> file("${buildDir}/resources/main/static/fineract.yaml"),
sourceSets.main.runtimeClasspath.files)
> }
> ```
>
> The idea would be to preserve explicit `operationIds`, generate
deterministic fallback IDs only for missing ones, and fail the build if the
final IDs are duplicated. So I'm not suggesting replacing the manual
`operationIds` you're adding here. I agree those still have value, especially
for endpoints where path + method would be awkward or less meaningful, is just
that from my perspective manual hardening alone does not fully solve the
maintainability problem, because untouched or future endpoints can still fall
back to unstable generated names. If you think it makes sense, we could open a
Jira ticket for that follow-up.
@San-43 That sounds good to me! I think the only potential issue I saw was
in generation. Detection not only works but is necessary to fix the underlying
problem just like you said. Please go ahead!
I will also mention though that completing operationIds on the remainder of
the deduplicated feign methods remains a blocker on this. So we might need to
wait on the rest of the endpoints to get modified. @Ambika-Sony Are you still
working on this?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
