* [core] Fix naming of reservedWordsMappings
* `GeneratorSettings` used a wrong name (missing `s`) which resulted in config loaded from YAMl files not working
* [dart] Respect reservedWordsMappings when checking for reserved words
* Adds UUID to python-exp, allows uuid models to be generated
* Adds test_UUIDString uuid model test
* Fixes uuid properties in python-exp, changes maps to object data type, adds uuid data type
* Adds maps data type back in
* Adds missing Null and AnyType definitions and adds them to python-experimental
* Generator docs updated, added missing uuid, null, anytype, and object
* Adds uuid support description
* Docs updated
* Revert "Revert "Has generators set default template engine (#11245)" (#11316)"
This reverts commit 57987424a4eaa22d73337388489cd86d7f42a023.
* Only loads in the default template engine if the config file contains the generatorName
* Only sets templatingEngineName using condif default in one place
* Adds config files that lack generatorName
* Revert "Adds config files that lack generatorName"
This reverts commit 7dafc93c0f02c037d9be5d2c0a3ee7377c8b479d.
* Adds generator default templating engine to the generator metadata
* Remove redundant operations
* Use logger correctly with object placeholders
* static compile of frequently used pattern
compile pattern ahead of time to reduce object creation and optimize
method
* Fix typo in method name
AutoRefactor cleanup 'AnnotationCleanUp' applied by erefactor:
Simplifies annotation uses:
- empty parentheses will be removed from annotations,
- single members named "value" will be removed from annotations and
only the value will be left.
For AutoRefactor see https://github.com/JnRouvignac/AutoRefactor
For erefactor see https://github.com/cal101/erefactor
* [maven] Fallback to templates using classpath rather than OS-specific paths
Previous checks would cause logic in Windows to return early, for
built-in templates only. This reorganizes and simplifies the ordering
behavior.
* Match classpath check in WorkflowSettings with that in TemplateManager
* [maven] Much needed unit/integration tests
This follows similar approach used in PMD and other plugins managed by
maven.
Unit tests simply verify we can load configuration as expected into the
Mojo.
Integration tests execute actual sample projects bound to the current
build's Maven plugin. This uses maven-invoker-plugin, which also allows
for specifying the maven options in invoker.properties to execute the test.
It also provides a verification framework using groovy files with the
required naming convention of "verify.groovy". This allows us to quickly
and easily check that certain files are outputted by generation, and we
may also spotcheck file contents.
templateResourcePath option is skipped on windows. I've tested back to
version 3.3.3 and this doesn't seem to have worked consistently with how
the property works on non-Windows.
* Set groovy 3.0.5 for test harness
* Print stacktrace on Maven error in Travis
* [maven] Set groovy version in tests to supported in Java 11+
* Puts maven integration tests in separate profile called 'integration'
* 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
-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.
* 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
* Fixes issue with templates loading via classpath
The templating engines were originally written to load templates via the
classpath, but this functionality was blocked by file-only checks
further up the stack. This loosens those file-only checks, allowing
files and relatively imported files to be included via classpath.
* [docs] Add details about classpath-level templates
* [feat][maven] templateResourcePath for template on classpath
- NOTE templateResourcePath is not needed for gradle, as it accepts
a string for the target template directory, which supports classpath
* [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
When WorkflowSettings was constructed from an existing instance, as is
the case when we deserialize from an external configuration file, it
would result in an error:
Caused by: java.lang.UnsupportedOperationException
at com.google.common.collect.ImmutableMap.put(ImmutableMap.java:450)
at org.openapitools.codegen.config.WorkflowSettings$Builder.withSystemProperty(WorkflowSettings.java:465)
This was due to an error in `newBuilder(WorkflowSettings copy)` which
assigned builder.systemProperties with an immutable map. This is
incorrect because everything in the builder should be mutable until
.build() is invoked.
This likely affects CLI/Maven plugin as well for version 4.1.1 through 4.2.0.
* Fixes NPE when no outputDir is set
* Fix behaviors of default values for values not provided by user
* Easier handling of default behavior in settings.
* Fixes for dynamic config deserialization (specifically, ruby client sample fix)
* Tests for WorkflowSettings (defaults, modified defaults, nulls)
* Test modification of WorkflowSettings defaults for both class constructor and builder
* 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
* Initial implementation of a validation framework in core
* Print surefire summary (helps evaluate errors)
* Bump versions: surefire plugin,jmockit
* Depend on jmockit within maven-surefire-plugin which requires it
* 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
* 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.
