* update to jdk11, fix tests
* update workflow to use jdk11 instead
* update travis, circleci build
* fix test failure, update CI
* skip mvn install in appveyor
* add windows tests
* fix workflow
* remove log level
* add timeout
* sleep more
* skip tests
* sleep more
* only skip tests
* test with jdk11 only
* fix gradlew
* remove skip tests
* start server after build
* update gradle version
* more time to start server
* update to 420
* comment out build
* update
* update
* Upgrade Gradle plugin Gradle build to Gradle 7.5.1
* Update Travis workflow file to support new tasks
* Update Maven POM with Gradle 7.5.1
* Capitalize many occurrences of "Gradle" in the Gradle plugin README
* Update Gradle version in appveyor.yml and shippable.yml
* Update comments
* Update Gradle wrapper to 7.5.1
* Capitalize Gradle in shippable.yml
* Leave Open API
* Upgrade Gradle plugin build to Gradle 7.6
* Upgrade wrapper to Gradle 7.6
* Add cacheability tests for same directory and different directory
(cherry picked from commit 46c96daf3b020ab02e13113166046d2383c04990)
* Clean up/add more cacheability tests
(cherry picked from commit 5d09d914ba7224b82dd7a3bd20beaf2b6fd3eb94)
* Add test for inputSpec
(cherry picked from commit 8d9e0dbb9d865ad3e61b60692b3ef6ca85b70b75)
* Add incremental build tests, run with multiple Gradle versions
(cherry picked from commit ba1d554c375068974d1799d6be6731ca1d59a783)
* Add proper Input annotations to task inputs
(cherry picked from commit 18da6161ba2b406876c516a3059850d9a0bc9ca0)
* Perform clean on tests where expectation is cleaned outputs
(cherry picked from commit 4670db92686c02d5dd2b69976488c33defd3a464)
* Ensure before & after files are the same
(cherry picked from commit 9150b4a5596b229a4404a92cfedbb795c6bb5b0d)
* Allow to run ValidateTask tests against Gradle 7.0 as well
* Drop setters for ValidateTask properties of mutable types
This is applicable to the following properties:
- inputSpec
- recommend
Otherwise, Gradle 7.0 now returns an error when attempting
to configure this task.
See https://docs.gradle.org/7.0/userguide/validation_problems.html#mutable_type_with_setter
* Be more specific about the versions of Gradle tested in ValidateTaskDslTest
Test against the latests Gradle 5.x and 6.x versions
Motivation:
In Gradle 7.0 apply @Input and @Internal on property is forbidden.
Before Gradle 7.0 applying both on the same property is confusing. According to the documentation:
* @Input: Attached to a task property to indicate that the property specifies some input value for the task.
* @Internal: Attached to a task property to indicate that the property is not to be taken into account for up-to-date checking
Tests running under Gradle 5.6.4 were breaking due to a change in
informational output. It's not clear when this was introduced, but it
looks like the upgrade to Gradle 5.6.4 may have stopped running tests
during builds.
* [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.
* [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
