* Ensure CLI-level generator settings are available in additional properties
* Initial conversion to yaml configs
Configs prefix with 1- need to be manually evaluated.
* Add "other" configs not in ensure-up-to-date
* Add other/openapi3 files
* Cleanup all generation scripts
* Clean up: add missed configs and fix some openapi 3 diffs
* Move generate-samples script, error on batch failures
* Temporarily disable elm which requires skip validation of spec
* CI updates (todo: run all generators through appveyor or move to github workflows)
* Add success count to batch generation command output
* [samples] Regenerate
* Remove bin/windows
* Generate swift5 samples in bitrise
* Expand user input glob pattern
* Regenerate samples
* Update PR template
* Support config based generateAliasAsModel
* [samples] Regenerate
* [rust] Generate as alias for all samples configs
* [csharp] Move test staged file changes to in-directory
* Include "live" test files and ignore test cache files from samples.ci
* Remove concept of samples.ci staging
Generators support .openapi-generator-ignore, allowing maintainers to
explicitly ignore the regeneration of files which have been modified.
Note that the tooling does not overwrite test files whenever those files
exist, and it's not entirely necessary to add test files to the ignore
file.
* Re-add meta generator scripts
* Modify ensure-up-to-date to log stdout, so script does not look like it hangs on slower machines
* [csharp] Regenerate sample
* Set generateAliasAsModel CodegenConfigurator#toContext
This ensures the property (which is effectively a thread-local) gets set
as expected if the caller resets GlobalSettings as is done in the
GenerateBatch command.
* [rust] Regenerate samples
* Re-enable elm
* [java] Support OffsetDateTime example, fail ensures script on any generation error
* [samples] Regenerate
* Fix jersey2-java8 ignore file
* Fix elm spec validation
* Force UTC in sample generation to avoid timezone conflicts during generation (user vs ci)
Co-authored-by: William Cheng <wing328hk@gmail.com>
* [breaking] Enforce vendor extension naming convention
* [breaking] Rename system properties to global properties
* [docs] Update site with global properties list and usage explanation
* Use proper vendor extension casing in all templates
* Set remaining vendor extensions to convention of lower kebab-cased with x- prefix
* [samples] Regenerate
* Update modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/RustServerCodegen.java
Before we were adding hasPathParams twice, once with !op.pathParams.isEmpty(), and then again with hasPathParams. This was probably caused by a mistaken merge.
This is causing the difference in samples
Co-authored-by: Richard Whitehouse <richard.whitehouse@metaswitch.com>
* [Samples] Regenerated!
* Fix -D conversion to additional-properties, missed in bat files
* JERSEY2 option changed
* [samples] Regenerate
* [scala][finch] Fix remaining vendor extensions format to conventino
* [scala] The -D option was replaced with --global-property
* [samples] Regenerate
* Fix -DskipFormModel usage which has been moved to --global-property skipFormModel=true
* [samples] Regenerate
Co-authored-by: Richard Whitehouse <richard.whitehouse@metaswitch.com>
* [core] Refactor templating management
This refactors template management to get logic out of DefaultGenerator
and to provide a cleaner API to template search and read/compile.
Deprecates MockDefaultGenerator, which is not a mock and causes
in-memory retention of file contents. Maintainers should prefer
executing a "dryRun" with new DefaultGenerator(true) or do true
mock/spies if evaluating template intermediaries is truly necessary.
Tests may read written files with lower overhead than the in-process
retention of those bytes.
This attempts to maintain some compatibility with existing templating
adapter interfaces. Any breaking change here would be unintentional but
minimal effort to retarget the new interface.
* Tests for dry run file outputs
* Update API usage in Meta, test TemplateManager
* Wait on lastModified, lookup by filename in SpringCodegenTest
* Test DefaultGenerator + ignore file
* Move config.processOpenAPI in DefaultGenerator
* Fix wrong use of libraries templateDirector (java)
The samples scripts for Java incorrectly referenced the libraries
directories directly rather than the upper-level Java directory. This
was incorrect usage of template directories, because the generator
expects to be given the "language" directory and perform a lookup for
missing templates in the order:
* user defined libraries directory
* user defined language root
* embedded libraries directory
* embedded language root
* _common directory
This is incorrect in our samples scripts because a user or maintainer
has the expectation that any template change to files at the Java/ root
should also be honored on generation if the script specifies a custom
template directory.
* Fix handlebars extension usage, clean up Meta tasks
HandlebarseEngineAdapter previously didn't handle files without
extensions in the same was as the MustacheEngineAdapter. This now allows
for files without extension (or dotfiles) to lookup in the same
location.
Meta tasks are cleaned up to use template manager only, rather than
attempting to create an "empty" generator to use the previous templating
specific methods.
* Update kotlin-multiplatform gradle wrapper
* Rename GraphQL .gitignore template
The .gitignore file is unable to load via classpath resource from the
graphql node server resource directory (for unknown reasons). Before
this change, the missing template would fail silently.
A .gitignore file may exist in other directories and load as expected.
Added a default .gitignore to _common as a fallback so as not to break
any custom generators which may also be failing silently.
* Log entire stacktrace in go sdk built by gradle in AppVeyor
* Rename PHP .gitignore to gitignore
Java resources may not load .gitignore, this follows suit with other
generators and uses "gitignore" (some use "gitignore.mustache").
* [php] Rename .gitignore templates to gitignore
* Use same classpath lookup in common locator
* [rust] Properly escape empty triple-braces
* [samples] Regenerate
* [cli] new 'author template' command
This new command allows users to extract templates for authoring
(customization) without the complexity of finding and downloading a
specific directory for their versioned artifact.
Example usage:
```
openapi-generator author template -g java --library webclient
```
This will write all templates with library-specific templates to the
'./out' directory relative to the current directory.
CLI will refer the user to
https://openapi-generator.tech/docs/templating after generation
* [docs] Usage of author template command
* Log warning if author template fails to output requested library
* Adds addComposedMappedModels and testComposedSchemaOneOfDiscriminatorMap
* Requires that discriminators be required properties
* Strengthens discriminaotr validation, adds better error messages, adds schema oneof samples
* Adds oneOf and anyOf invalidDiscriminator tests
* Updates incorrect addOneOfInterfaceModel invocation
* Runs ensure-up-to-date
* Adds updates from Sebastien Rosset
* Removes newlines
* Uses df.isString
* Fixes tests be correctly setting df.isString
* Updates discriminatorExplicitMappingVerbose description per PR feedback
* Adds description of how mappedModels is populated
* Adds the suggestion exception raising when a MappedModel mappingName is null
* Actually resolves merge conflicts
* Switches two methods to package private because they are needed for testing
* Allow nulls in MappedModel.getMappingName
* Updates CLI flag name to legacyDiscriminatorBehavior, default=true
Co-authored-by: William Cheng <wing328hk@gmail.com>
-D option has been deprecated as it was previously used to:
* Pass "system properties"
* Pass additional properties
This was confusing because we already have --additional-properties and
because Java System Properties are passed as -D before program
arguments.
Confusion around the -D option had existed for some time, but when we
introduced the thread-safe GlobalSettings to avoid overwriting Java
System Properties, we created a hard break from Java System Properties
in the generator. This also disconnected the previous "system
properties" from accepting additional properties.
Once these newly deprecated methods are removed, we will have a clear
separation of concerns between:
* Java System Properties
* Global generator properties (used as workflow context)
* Additional properties (used as generator options)
This commit marks multiple places for cleanup in 5.0. These will be
breaking changes, and lower effort to break in 5.0 with deprecation
warnings now rather than adding sibling properties throughout the code
and potentially introducing logic errors.
* [cli] Some CLI improvements…
* Introduce --version
* Introduce --help
* Add --sha to version command for short SHA display
* Output Version and SHA details
* In new --version output, display repo and doc site
Additional cleanup to suppress warnings and code quality.
* [docker] Adds labels for metadata
This adds image labels to store metadata on the online and cli docker
images, using standard labels:
* org.opencontainers.image.created
* org.opencontainers.image.revision
* org.opencontainers.image.title
* org.opencontainers.image.version
These can be inspected via 'docker inspect IMAGE_NAME' and may be useful
in tooling/automation or bug reports submitted by users.
For more details on these labels, see:
https://github.com/opencontainers/image-spec/blob/master/annotations.md
* Include version --full for equiv to --version
* [cli] Validate now uses parseOptions w/setResolve
The validate command now uses ParseOptions#setResolve(true) to match how
we parse in CodegenConfigurator and online's Generate. Without this
option, the OpenAPI 3 parser skips the "resolve" block, which made lead
to validations in the command not matching validations during
generation.
* [gradle] Validate now uses parseOptions w/setResolve
The Graldle validate command now uses ParseOptions#setResolve(true) to match how
we parse in CodegenConfigurator and online's Generate. Without this
option, the OpenAPI 3 parser skips the "resolve" block, which made lead
to validations in the command not matching validations during
generation.
When I originally implemented the feature set code, I added the
getter/setter on DefaultCodegen and CodegenConfig as well as on
GeneratorMetadata. GeneratorMetadata also includes the library variation
features. When I went to add library-specific features, I realized the
discrepancy.
This removes the public setter from DefaultCodegen/CodegenConfig, and
adds a protected modifyFeatureSet which accepts a lambda and hides the
builder logic away in the method.
This will be a breaking change for anyone who's created a custom
generator in 4.2.3, so the impact is very limited.
* 👕🎨 Minor refactor DefaultGenerator
This cleans up some lint warnings and improve general code cleanliness
of DefaultGenerator.
Specifically:
* logger strings are now using the built-in log formatter rather than
constructing new strings regardless of log level.
* Diamond operators are used where possible
* Some long-unused commented code has been removed
* Lambdas are used where possible
* Redundant operations are merged (HashMap constructor used rather than
subsequent putAll on a collection, for example)
* [cli][core] Add support for dry-run and display
CLI now supports `--dry-run`, which will output a file change status
similar to git status --porcelain.
The user may also specify `--verbose` for a one-liner below each file
explaining why the change operation might take place.
* [docs] Upgrade to Docusaurus 2
Due to formatting issues with Docusaurus 1 and code blocks, and upcoming
4.3 and 5.0 releases, this is an upgrade to have more control over
formatting and other functionality.
This adds behavior to have light/dark themes.
As a consequence of upgrading, columnar format on ul element in
generated generator docs had to be moved to css. This will not impact
users viewing the markdown on GitHub because it didn't display the
column format.
This upgrade should improve syntax highlighting and performance.
* Fix user page layout, choose theme with clear diff colors
* [core] Normalizing vendor extension naming
According to [OAS 2.0][1] and [OAS 3.0][2] Specifications:
> Allows extensions to the OpenAPI Schema. The field name MUST begin with x-,
> for example, x-internal-id. The value can be null, a primitive, an array or an object.
> Can have any valid JSON format value.
This commit attempts to define a [clear identifier design format][3] of
maintaining lower-kebab casing and following the x- prefix defined by
OAI Specification.
Following a convention that matches that used by others (see [autorest][4]), we will remove
any confusion about naming strategies for template authors and
customizers. Following the lower-kebab convention will allow us to
convert from camelCase and missing prefixes to the desired format. For
example, these conversions are simple to make for template consistency:
* customValue => x-custom-value
* x-customValue => x-custom-value
* x-custom-value => x-custom-value
This convention also allows us to define a single standard for use
across all generators. This means no occurrence of x-operationId in one
generator and x-operation-id in another.
[1]: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#patterned-objects
[2]: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.2.md#specificationExtensions
[3]: https://tools.ietf.org/html/draft-wilde-registries-01#section-3.4
[4]: https://github.com/Azure/autorest/tree/master/docs/extensions
* Incorporate feedback to avoid race/blocking in OnceLogger
* Remove unnecessary additional log config
* Add tests,comments for OnceLogger
* Test caffeine cache with FakeTicker
* Flatten feature sets for display
* [cli] Add feature set output to config-help
This includes markdown and plain text outputs for config-help.
* [docs] FeatureSet on generator docs
* [core] Extracting recommendations to validation framework
This is work to extract recommendation logic out of the CLI validate command
into a shared evaluation instance which can be used elsewhere (such as Gradle,
or the Online tool).
For now, these validations are in addition to those provided by swagger-parser and
are only the following recommendations:
* Apache/Nginx warning that header values with underscore are dropped by default
* Unused models/schemas
* Use of properties with oneOf, which is ambiguous in OpenAPI Specification
I've allowed for disabling recommendations via System properties, since this is
something that has been requested a few times by users. System properties in this
commit include:
* openapi.generator.rule.recommendations=false
- Allows for disabling recommendations completely. This wouldn't include all warnings
and errors, only those we deem to be suggestions
* openapi.generator.rule.apache-nginx-underscore=false
- Allows for disabling the Apache/Nginx warning when header names have underscore
- This is a legacy CGI configuration, and doesn't affect all web servers
* openapi.generator.rule.oneof-properties-ambiguity=false
- We support this functionality, but the specification may not intend for it
- This is more to reduce noise
* openapi.generator.rule.unused-schemas=false
- We will warn when a schema is not referenced outside of Components, which
users have requested to be able to turn off
* openapi.generator.rule.anti-patterns.uri-unexpected-body=false
* Move recommendation/validations to oas package and add javadoc comments
* Refactor and test recommendation validations
* Refactor validation function signatures to return explicit state rather than boolean
* Add operation recommendation for GET/HEAD w/body
* 🐛 Fixing some issues with threading and NPE
After running Sonar on the master branch, some major analysis
opportunities were displayed.
This fixes the use of SimpleDateFormat stored as static fields.
SimpleDateFormat is not thread-safe, and may retain data across threads.
While there's no indicator that this has caused any issues (these are
mostly used for example code), we should follow these best practices.
This also fixes a handful of NPE and other minor issues such as
comparing Boolean.TRUE to strings and no wrapping some closeables in
try-with-resources.
* [cli] Unit test GenerateBatch custom deserialization helper
* Quiet batch mode in sonar.yml
* Suppress unnecessary warnings (ThreadLocals in static fields)
* [test] Removes jmockit in favor of mockito
We use mockito in many tests. This removes jmockit which is run as a
javaagent in favor of Mockito which is not.
This work is in preparation for applying some static analysis tools,
while evaluating others such as Jacoco. I'm also look at ways to improve
build times while also decreasing "ramp up time" for contributions from
the community. Reducing the number of mock frameworks and dependencies
is a step toward that goal.
* Rename method in new.sh
* [cli] Mock the generate task
* [config-help] Sort all outputs
* Remove old/stale generator docs (these have been renamed previously)
* Sort config doc outputs, making it easier to find relevant info
* Fixes cliOptions duplicates
Erlang client/proper improperly set the version option as packageName
(causing duplicate for packageName).
The java and swift option removals are because the options are added in
parent classes, resulting in duplication of the options.
* Add --github-nested-index for generating docs/generators/README.md
* 📝 Regenerate generator docs
OAS 3.x specification isn't entirely clear on oneOf support. JSON Schema
defines oneOf in such a way that the Schema is only valid if it
validates against exactly one of the referenced Schemas. This suggests
that a Schema defined with oneOf can't include additional "dynamic"
properties. OpenAPI extends on this by adding the necessary
discriminator object, which allows tooling to decide the intended
Schema.
As tooling, openapi-generator may support loose or confusing definitions
in the Specification to better support our user's use cases. In this
case, we may warn that while this usage is technically valid the two
target specifications are unclear about the actual constraints regarding
oneOf.
* [cli][batch] Better glob support
If invoked as `openapi-generator batch *.yaml`, the command might
previously fail in some shells where `*.yaml` expands to file name only.
This supports globs without path-part in the filename to prevent
possible NPE.
* [cli] Document batch command
* [meta] Support Kotlin meta generator
* Guard against automatic scripts (assumptions for this script are not fulfilled by some CI which run "run all" type scripts)
* [docs] Updating docsite outputs to be browsable on Github as well
* Fix links to other files
Suffix `.md` was needed to make links works
* [docs] Add clarification to differences between customization and templating docs
* [docs] Collapsible side bar, scroll to top, minor enhancements
* [CLI] Initial implementation for batch generation
Allows for generating multiple outputs via config. Just specify multiple
config files on command line.
Intent for this is to reduce CI times to generate outputs as well as to
reduce time for users to run ensure-up-to-date to meet PR standards.
Example command:
openapi-generator batch --includes-base-dir `pwd` --fail-fast -- bin/ci/*
---
As part of this implementation, the batch command support a customized
JSON key, `!include`. If this key's value refers to an existing file,
that file's contents are "unwrapped" into the config during
deserialization. This allows us to easily point to the same configs used
by our sample scripts without modifying the CLI generate task's switches
or assumptions.
* Allow for path-relative outputs
* Add batch JSON objects
* Include INFO log about threads used and includes/root
* Ensure GlobalSettings.reset()
* Improved thread-safety of ModelUtils
* Filter deprecated generators from CLI list by default.
* [gradle] Exclude deprecated generators from list by default, add "include" option to allow for customization of list task.
* Update scripts to support the --include option of the list command
* Update gradle/cli docs for generators listing with "include" option.
* [core] Initial support for server variable overrides
* [gradle] Support user overrides for serverVariables
* [core] Clarify server variable overrides, and propagate them to templates in the "servers" array
* Introduce GeneratorSettings + cleanup
GeneratorSettings is an immutable settings object, intended to limit the
manipulation of generator settings.
To move to GeneratorSettings, lots of modification was done to
CodegenConfigurator. The goal here is that CodegenConfigurator
would create the contextual information required to initiate a
generator run:
* GeneratorSettings
* Workflow related settings
* Configuring "system" GeneratorProperties (ThreadLocal properties)
* Deserializing from file to config object
* Input spec document (OpenAPI, intending to target others)
ClientOpts was generally unused, and the few places it was being used
have been updated to pass the properties to
codegen.additionalProperties.
* Add sanity to system properties
The -D argument for the generate command is an application argument
which is easily confused for Java System Properties. This isn't the
case, as setting values here doesn't update the configuration in
System.getProperties().
This adds a warning and deprecation to that option, as defining these
values as system properties will also continue to work as expected. This
makes the -D application argument redundant and confusing.
* Contextualize generator/workflow settings
This splits settings relevant to generator configuration (the what) and
workflow configuration (the how) in an attempt to make configuration
easier to conceptualize.
* Update Gradle task w/ CodegenConfigurator setters
* Remove -D usage in scripts
* Add -p option for additional properties
* Regnerate samples
* [feat] Intro GeneratorMetadata (stability index)
GeneratorMetadata offers an immutable object created via Builder pattern
which allows generators to explicitly define their stability (stable,
beta, experimental, deprecated) as well as a message to be shown during
generation.
This is a step toward:
* Fleshing out the "Core" artifact (#845)
* Providing a place to encapsulate feature-oriented metadata (#840)
* Providing a means to communicate end of life scheduling (#116)
This new structure, specifically the Stability property, allows us to
offer future enhancements such as allowing users to filter down to only
"Stable" generators via CLI, and eventually any compat table (see #503).
* Mark deprecated generators as deprecated in-code
* Re-export docs/generators.md
* [all] Adds strict spec option
Introduces an option to allow user customization of strict specification
behaviors. For instance, OpenAPI 3.x requires a path object name to be
prefixed with '/' so we append any missing '/', but this may not be
desirable to some users or generators. In this commit, this fix specifically is
the only modification affected.
* Clarify strict-spec docs, add option to README.md
* Update CLI options in docs/usage.md
* [cli] Support packageName as global option
CLI supports other package-related options (--api-package,
--model-package, --invoker-package). This aligns those options with
--package-name to avoid confusion about how to configure these options
where those are supported.
This intentionally does not apply a packageName getter/setter to
DefaultCodegen to reduce the footprint of this change.
* [gradle] Add packagName as global option
This makes packageName available as a global option, beside apiPackage,
modelPackage, and invokerPackage to reduce potential confusion about how
to configure the four of these options by generators which support them.
* new module: openapi-generator-core
* templating engine adapters to support extension (currently only Handlebars)
* new `-e` templating engine CLI option
* adapt Generator to process Template with the passed TemplatingEngineAdpater
* add a MustacheEngineAdapter to the codegen in the unit tests
* force default MustacheEngineAdapter
* copy new core module in the root Dockerfile
* add processTemplatingEngine to CodegenConfig, to be overriden by Codegen classes if needed
* support multiple file extensions per templating engine adapter
* Extends handlebars experimental adapter with explicit contextual resolvers (e.g. map processing)
* Add new openapi-generator-core/pom.xml to release_version_update.sh
* A detailed message will be logged on missing handlebars helper
* Adds README documentation around template default and beta options
* Moves mustache package under new templating package
* Include built-in handlebars helpers which require explicit registration, and custom `startsWith` helper.
