* #18058 Fix AbstractJavaCodegen.getAccepts() so it returns a String array instead of a comma-separated string, and fixed api.mustache so the @RequestMapping annotation generated produces for x-accepts as a parameter list instead of a (single) string.
* #18058 Updated test case to accept a string array instead of a comma-separated list.
* #18058 Reverted changes on imported compared to the main branch.
* #18058 getAccepts() is now hybrid, and can return both a single String or a String[].
* #18058 Rolled back the hybrid getAccepts(), so it only returns a String array.
* #18058 Updated mustache files to cope with vendorExtensions.x-accepts being a string array instead of a comma-separated string.
* #18058 Generated new sample files with by running `./bin/generate-samples.sh ./bin/configs/*.yaml`
* #18058 Optimization of getAccepts()
* #18058 Regenerated scripts that got broken after resolving conflicts on GitHub
* #18058 Fixed introduced issue with api.mustache causing a redundant accept with @HttpExchange with the PetApi.java, StoreApi.java, and UserApi.java.
* 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
The EOL is missing so let's add it in order to comply with POSIX standard:
Line
> A sequence of zero or more non- <newline> characters plus a terminating <newline> character.
* Add serialVersionUID to Java apiException.mustache templates
* Use 'enable()' and 'disable()' methods to handle object mapper features in JSON.mustache for the "native" Java generator instead of the deprecated 'configure()'
* Update samples
* fix: change indent style to tab in the mustache to generate Go code
* docs: standardize the language names for code blocks
* docs: change indent style to tab in the code blocks
* update: regenerate samples
* `./bin/generate-samples.sh ./bin/configs/*.yaml`
* Delete sample folders of discontinued clients
* Remove duplicate python-flask server sample
The python-flask sample actually lives in samples/server/petstore/python-flask.
* Move hand-written test to "tests" folder
Now, "test" only contains generated stubs and all hand-written tests are in "tests".
* Delete left-over files in Python samples
These are not created by the generators (anymore) and not hand-written
for testing.
* Regenerate test file to fix import error
* [Ruby] Add support for gems metadata
This defaults to an empty hash, but can be overridden with any custom
object by the callers via the `gemMetadata` property.
* Regenerate samples
The gemspecs files will now include a metadata field
* Add support for all +json and +xml suffixed media types to generated Go client
* Export JsonCheck and XmlCheck and add external tests
* Remove client_test.mustache
* upgrade spring-boot-starter-parent
* upgrade springdoc and swagger-ui
* upgrade v3 swagger-annotations
* generate samples
* upgrade jackson
* fix spring cloud, remove temp comment
Putting "8" instead of "1.8" should be ok, because Spring Boot 3 requires Java 17 anyway, so it should be able to understand that 8 is the same as 1.8.
* generate samples
* upgrade JUnit 5, remove commons-io dependency, remove outdated samples/client/petstore/java/feign/feign10x/ files, generate samples
commons-io dependency was introduced in https://github.com/OpenAPITools/openapi-generator/pull/8484, but I don't see why it would be needed now or back then.
* update gson, generate samples
* update logback
* update feign
* update scribejava
* generate samples
* update httpmime
* okhttp-gson: update commons-lang & okhttp & junit-platform, remove mockito; generate samples
It seems Mockito is not used at all there.
* okhttp-gson: remove unnecessary sample files, generate sample files
* upgrade google-api-client & jersey-common, restore ClientTest, generate samples
* misc. upgrades in jersey2 and jersey3
jersey 3.1.3 is available already, but IntelliJ reports security problems in 3.1.3 and 3.1.2, so I used 3.1.1 instead.
* align some gradle&sbt files with poms, generate samples
* whitespace fix
* [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
* Add apiNameSuffix to AbstractGoCodegen
* Regenerate files
* Update tests
* Regenerate files
* Update test files
* Regenerate for CI test
* Regenerate for CI test
* Remove some docs
* Add files back
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.
* Probe content type for multipart form uploads since many servers require each part to correctly identify its type.
* Update samples
* Add explanatory comment
* Update samples with comment
