* [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.
* [gradle] Add recommendations to validate task
* Use current version of Gradle Plugin in build checks.
* Fix gradle project build version confusion in CI
* [gradle] Bump samples to 5.2.1 wrapper
Previously, the Gradle plugin was building in CI against
openapi-generator 4.2.0 and Gradle version 4.10.2. At some point, a
contribution was made with an API which is incomatible at 4.10.2 and due
to a release script error which pinned the local-spec version to release
4.2.0, we didn't notice this inconsistency.
This bumps the project to build against Gradle 5.2.1.
* 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
* [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.
This allows easier creation of custom `GenerateTask`. Specifically, this makes:
- generateModelTests
- generateModelDocumentation
- generateApiTests
- generateApiDocumentation
- withXml
optional, following the same pattern as other properties in GenerateTask.
Without this change, we get `java.lang.IllegalStateException: No value
has been specified for this provider.` until these properties are
specified for the task, when attempting to define a custom generate task
(such as one to generate API docs).
* [gradle] Add 4 boolean properties supported by codegenConfigurator
* [gradle] Add Windows workaround for Android Studio
After release 3.0.0, a guava dependency was updated and this exposed an
issue in Windows where Guava's CharMatcher.ASCII is called to validate a
path. The version of Guava referenced by OpenAPI Generator causes a
'NoSuchField' error because the referenced dependency names this static
field CharMatcher.Ascii.
This error is not surfaced on macOS, and appears to be Windows-specific.
This adds a potential workaround to the Gradle plugin's readme.
See #1818 for more details.
* Support Gradle 4.10
Gradle 4.10 is bundled with Kotlin 1.60 and Kotlin DSL 1.0-rc1. The new
Kotlin DSL isn't binary compatible with the `tasks` registration used in
this plugin.
Updating to Kotlin DSL 1.0-rc1 with no other changes would require users
to update to Gradle 4.10.
As a workaround, I've modified the tasks registration being done in
OpenApiGeneratorPlugin.kt, so rather than using the Kotlin DSL's invoke,
it creates tasks manually against the TasksContainer. This works locally
with Gradle 4.7+ for all scenarios in the sample (samples/local-spec).
There may be edge cases that I'm unaware of, and we may want to consider
defining the minimum supported Gradle version of 4.10 in the next major
version of openapi-generator-gradle-plugin if we experience those cases.
* Uncomment snapshots repo (commented it during local testing)
* update pom.xml for exec gradle plugin
The gradle plugin sets all System properties before generation, then
reverts them back to their original state.
System.getProperty/setProperty return null if the property was not
previously set. The Kotlin map was defined with non-nullable key/value
constraints, so setting something not commonly set (modelDocs: "false")
would result in an runtime exception.
This changes the map to support nullable values, and rather than setting
a null System property at the end, it clears those which previously had
no value.
* Validate spec on generation by default
Adds a validation parameter to CodegenConfigurator, and passes through
options from CLI, Maven Plugin and Gradle Plugin to that property.
Default is to validate the spec during generation. If spec has errors,
we will output errors as well as warnings to the user.
Option can be disabled by passing false to validateSpec (Maven/Gradle)
or --validate-spec (CLI).
* Prepare version 3.1.1-SNAPSHOT
* fix version
* Use last prod version for the sample
* Update README.md
Fix
* [cli] Option parser does not support true/false for boolean options
* [gradle-plugin] Initial commit
* Clarify comments on file constraints
When a user sets the models, apis, or supportingFiles environment
variables, any one of these being set disables generation for the other
two. This could be confusing to users, so I've added some clarification
text in the comments for these properties.
In addition, I've cleaned up the extension on
Property.ifNotEmpty, to avoid using Suppress annotations where it's not
necessary. The change creates a local variable of type T?, allowing
Kotlin to track the variable's nullable state at compile time.
* Move gradle plugin under modules
* Move kt files under kotlin source set. Add sample.
* [gradle] map-like options as maps
* Add tests for gradle validate task
* Apply gradle plugin to mvn install phase
* [gradle] Testing remaining gradle tasks
* Add gradle plugin to the integration doc
* Update gradle plugin README with task options
* Gradle readme formatting
