* add initial openapi config and java generated files
* add java implementation for adding generator version
* regenerate sample client files
* remove tabs
* only show generated version if build info exists
* set build info for batch generation
* update generator doc for new global flag
* use existing property for generator version
* update templates to include generator version
* update templates for better generator version syntax
* revert undesired changes
* regenerate samples for openapi client
* update templates to correct formatting/newlines
* correct description text and add to usage doc
* add generator cli option for all codegen types
* use more concise version info; update existing codegens to support new prop
* correct wrong prop reference
* add initial test coverage for new prop
* update last (scala) templates with new prop
* update samples after upstream merge
* use consistent version output
* use better sample project id/name
* revert using option for generator version in templates
* fix #16797 and #15796 spring child constructor missing parent params
* root cause and update the DefaultCodegen.java to add missing property when with multi inheritance
* rollback SpringCodegen.java
* update samples
* rollback with master cause #16992 fixed this issue too
* still using orignal design
* catchup master
* catchup master
* catchup master
* fix
* add tests
---------
Co-authored-by: dabdirb <dabdirb@gmail.com>
* [ruby|client] Fix unmarshalling errors of enums inside other objects
Ruby|Client autogenerated model classes for Enums do not expose openapi_one_of
method. Instead they expose openapi_any_of method like:
# List of class defined in anyOf (OpenAPI v3)
def openapi_any_of
[
:String
]
end
Both types (objects and enums) do respond to build() method.
* Regenerate samples
* add nullable case to spring test spec
* generate samples for changed spring input
* add nullable case to general test spec
* generate samples for changed general input
* generate samples again
* generates samples again
* re-build from new sources, generates samples again
* [ruby] Not symbolize header param keys to allow the usage of underscore ("_") character
* use lambda to convert header key to a string if underscore is included
* [Ruby] Fix Operation Servers
* user `server_index` instead of `index`
* use nil as default
* add tests
* revert tests
* add tests to custom file
* add test file to ruby-faraday
As discussed in https://github.com/OpenAPITools/openapi-generator/pull/7415#discussion_r1113274416, it seems unlikely the code was correct.
server_operation_index is a hash table. In Ruby, `hash[key]` will return the value associated with `key`. If key is absent, `nil` is returned. Because that is sometimes undesirable, there is also `hash.fetch(key)`, which raises an error if the key is absent. It also allows you to specify a default to fall back on: `hash.fetch(key, default)` will return `default` if the key is absent.
So, since not all users will specify a 'server per operation' (or at least: I'm not), the old code would usually set `index` to the `server_index`, which is initialized to 0. The subsequent `if index == nil` will usually return false (`0 != nil` in Ruby), after which the `server_url` call on line 177 constructs the url based on the `server_operation_variables` and `operation_server_settings`, assuming we are dealing with the case where a server per operation is configured. The case where the url should be constructed from `scheme`, `host`, etc. is only called if either `server_index` is explicitly set to `nil` or the key `operation` is explicitly associated with the value `nil` in the `server_operation_index` hash table, both of which seem inappropriate.
* Enable the ruby client to support refreshing access tokens
- The client can now be configured with an access token getter proc
- The proc overrides the the static access token if it is set
* Run generators
* add isEnumRef to codegen property
* better format
* update R template to use isEnumOrRef
* update powershell template to use isEnumOrRef
* update samples
* [Ruby] Use Ruby autoload to lower memory usage and load times
Fixes#12648
Requiring all models up front can be very expensive in both time and
memory if there are many models. In an example client with 6000 models,
this would consume nearly 400MB of memory and take about 7 seconds to
load. This is mostly unnecessary as most users of the client library
will only actually use a small percentage of the library.
The changes in this commit use Ruby's autoload capability to defer the
loading until the constant is actually used. In that same example client
with 6000 models, when initially requiring the library, the memory
usage dropped to ~20MB and loaded in 0.3 seconds. As the constants are
loaded on-demand, the memory would increase towards that 400MB ceiling,
but if only a few constants are actually used, then memory will never
actually hit that ceiling.
An additional side effect of using Ruby's autoload is that the order of
declaring the constants is not important, as Ruby will naturally load
them in the correct order when they are needed. Thus, this commit obviates
PR #9103 and fixes#4690.
* add option to use autoload in ruby client
* test ruby clients only
* add tests
* update samples
* Revert "test ruby clients only"
This reverts commit 0aaf71cd4cc5d266f824b261a4d312f07bd589e5.
* update doc
Co-authored-by: Jason Frey <fryguy9@gmail.com>
