-
Notifications
You must be signed in to change notification settings - Fork 65
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 code generation to Ballerina PreBuildRunner task within the OpenAPI tool #4932
Comments
Client generations: While doing the client generation implementation, I encountered the following challenges
|
|
It is possible to get the resolved input file path using the relative input file path from |
Discussion to service generations:
|
As discussed, validation for the file input path, and target path will be handled via the plugin itself. |
The toml properties for build tools in
|
Meeting date: 2023/11/14
Our implementation plan includes the following key components within the OpenAPI tool in phase 1. |
Suggested subcommand This command is used to only update the Ballerina.toml with the command line details,; no code generation happens
Command options
|
We encounter a concern with the 'targetModule' value when the user has provided the same target module in two different config elements. In this case, the generated client will override the target module. This scenario can occur when the same tool has the same target module, and two tools share the same target module. |
While updating the Ballerina.toml, we encountered an issue with can not create a toml node for the toml element input in array type[1]. options.tags = ["1","2","3"] As a workaround we have to populate toml syntax tree by adding whole tool config to the toml as a string to exists syntax tree. |
Changes added to validate the |
The following changes were to the tool integration implementation with the recent improvements:
More details on these changes are documented in the developer guide. |
Currently, we need option locations for generating the diagnostics, with new changes we have limitations to getting location from the tool context since we receive |
This is fixed in ballerina-platform/ballerina-lang#42168 |
The current implementation assumes that the distribution provided tools cannot be accessed through the Central. If this were to be supported it would introduce other complications in other areas like tool resolution, compiler plugin resolution and language server and would require a lot of re-designing in those areas. |
Close this issue with the favour of ballerina-platform/openapi-tools#1616 |
Description:
This design considers a bal tool configuration as a build input. Such build inputs can be provided as CLI args, config elements in Ballerina.toml, or directly in the source code. The most obvious choice is the Ballerina.toml.
This needs to be applied to
The text was updated successfully, but these errors were encountered: