* Release versioning script with marker tags.
Introduces bump.sh which supports moving from version to version but
only within delimiting marker tags in the target file.
This script currently doesn't do validations or anything fancy.
* Allow bumping version according to type (major,minor,build,revision)
* bump.sh will display error if file contents are unchanged
* 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.
* 2nd attempt to make the automatic checkin testing work
* trying to submit the samples in hopes that the CI matches them and passes
* found some samples I hadn't updated. Maybe this is it?
* Iniital docusaurus based site
* Remove error about default local being used by String.format
* Change pinned users to represent global presence rather than alphabetical order pinning
* Include generator indexes in ensure-up-to-date (docusaurus site and /generators/README)
* Add Font Awesome attribution footer
* Remove feature callout until it is completed
* Include NPM try it out section
* Improve "Getting Started" type docs
* Include new custom template documentation
* Updating templating and customization docs
* Add vendor extension docs
* Cleanup templating page(s).
* Move users to yaml file for easy edit.
* travis configuration, and baseUrl mods to image URLs
* [docs] Migrate FAQ, release summary from wiki
FAQ has been split into multiple smaller documents to better categorize
and allow users to find what they're looking for (in docs folder or in
new website).
Release summary information (versioning strategy and cadence) has been
migrated from the Wiki and clarified a bit.
Also adds copy button for all code snippets in website.
* Copy current contributing/code of conduct to website
* [docs] Creating a new generator
* Clean up file output handling
This attempts to normalize all generators to use OS agnostic
File.separator.
It also cleans up some areas in code where we replace "." in full file
output path with File.separator. We should only be modifying directory
names we own, and should avoid modifying anything that can be provided
by a user.
It would probably be better to use Paths.get(…).toString() in all cases.
* Fix missed path separators in java codegen
* Adjust Java codegen path replacements
* Convert / in full path replacements, as / is forbidden in Windows, and noop elsewhere
* Use Paths.get where files are written, to better handle Windows path constraints
