Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Helidon SE 4 generation (clients and servers) #19150

Merged
merged 43 commits into from
Aug 4, 2024

Conversation

tjquinno
Copy link
Contributor

@tjquinno tjquinno commented Jul 11, 2024

Resolves #19148 to support generation of Helidon SE 4 clients and servers. (MP clients and servers were addresses in the earlier PR #18627.)

Resolves helidon-io/helidon#8879
Resolves helidon-io/helidon#8880

Key changes:

  1. Update the pom.xml template.

    • Several Helidon components have changed their GAV coordinates, and refactoring of code has created new components.
  2. Update workflows.

    Add the new v4 SE samples (one client, two servers) to the GitHub workflow triggers and scope. The second server sample selects the useAbstractClass option (note the -uac suffix in the directory and .yaml names) which creates quite a different project.

  3. Significant enhancements to the generated API and API implementation types.

    There are several new template files (used only for generation of Helidon 4-compatible projects) and, in some cases, substantial conditionalization of existing templates to differentiate between Helidon 3 vs. Helidon 4 (and later) generation.

    • The generated abstract class for each API contains generated logic to extract all inbound parameters into local variables which are then passed to the abstract handle<operationId> method. Each parameter is extracted in its own uniquely-named method so, if needed, developers can easily override selected methods. The generated code leverages features in Helidon 4 to decode each incoming parameter to the correct type.
    • The abstract class also contains inner classes, one for each operation in the API, which holds:
      • The methods for extracting each incoming parameter.
      • An interface Result with inner records for each response declared in the OpenAPI document for the operation. Each response record enforces required output headers and/or the response body output. As developers implement the handle<operationId> methods they can (but need not) use these records to easily prepare and send the HTTP response.
    • Improved validation. Validations specified in the OpenAPI document are applied to all incoming parameters and reported once, cumulatively, rather than flagging only the first violation.
  4. Many, many samples files are new or adjusted with this PR (leading to the large number of changed files).

PR checklist

  • Read the contribution guidelines.
  • Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
  • Run the following to build the project and update samples:
    ./mvnw clean package 
    ./bin/generate-samples.sh ./bin/configs/*.yaml
    ./bin/utils/export_docs_generators.sh
    
    (For Windows users, please run the script in Git BASH)
    Commit all changed files.
    This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
    These must match the expectations made by your contribution.
    You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
    IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
  • File the PR against the correct branch: master (upcoming 7.6.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
  • If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request. Java: @bbdouglas (2017/07) @sreeshas (2017/08) @jfiala (2017/08) @lukoyanov (2017/09) @cbornet (2017/09) @jeff9finger (2018/01) @karismann (2019/03) @Zomzog (2019/04) @lwlee2608 (2019/10) @martin-mfg (2023/08)

@martin-mfg
Copy link
Contributor

Hi @tjquinno, thanks for the PR! Could you please merge the latest master to fix the failing java-camel test? And update the samples, to fix the other failing check?
Other than this, the PR looks good to me. Although I didn't check in detail, due to the huge amount of changes.

@tjquinno
Copy link
Contributor Author

tjquinno commented Aug 3, 2024

@martin-mfg Done. Didn't realize I'd missed a few Helidon sample files in my earlier push but they are there now. Thanks.

@tjquinno
Copy link
Contributor Author

tjquinno commented Aug 4, 2024

@martin-mfg Thanks very much for the comments and the approval.

I do not have permission to merge PRs in this repo. I am not sure whether @wing328 would want to do so himself or whether that's something you could do on my behalf.

@wing328 wing328 merged commit 8f1d59f into OpenAPITools:master Aug 4, 2024
41 checks passed
@wing328 wing328 added this to the 7.8.0 milestone Aug 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants