In case the lifecycle phase is "generate-test-sources" the default output directory is:
"${project.build.directory}/generated-test-sources/openapi"
In case of any other lifecycle phase the default output directory is:
"${project.build.directory}/generated-sources/openapi"
Also use the "src/main/java" as the only default source folder in the output path for both
cases when addCompileSourceRoot == true and when addTestCompileSourceRoot == true.
In case you really need "src/test/java" it still can be set in the configOptions manually:
<configOptions>
<sourceFolder>src/test/java</sourceFolder>
</configOptions>
* [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
* Optimize: replace keySet + N get calls with entrySet saving N calls to get method in a few places
* missed one performance optimization
* Rolling back a change that was dependent on Java 11
The skipIfSpecIsUnchanged did not work when the input spec came from a
classpath resource, which could lead to infinite build loops when the
plugin was used in eclipse
#5805
* [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'
* [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>
-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.
* type aliasing issue
* Add example OpenAPI document from issue 3589
https://github.com/OpenAPITools/openapi-generator/issues/3589
* Add test to reproduce the issue
- type of TypeAlias changed from 'string' to 'object'
(not sure if importMapping is supposed also for 'string' types...)
- there might be better ways to write the test, it's kind of a brute
force test (generate a file and parse it with a regexp)
* Remove duplicate test file
* Add new method override handleMethodResponse
Fixes broken unit test after merge from master
Co-authored-by: bkoziak <bkoziak@gmail.com>
Co-authored-by: William Cheng <wing328hk@gmail.com>
The maven documentation was missing a few option, a couple of option
properties, and was inconsistent regarding selective generation for apis
an models. This adds properties and options where appropriate and
updates the docs. All options in the README have been reordered to match
property declaration order in CodegenMojo, hopefully making it easier
for maintainers to recognized when there are docs missing or out of
date.
This also slightly refactors the code in CodegenMojo to reduce the
cyclomatic complexity of the `execute` method.
* 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
* 🐛 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)
* This patch fixes the bug that we cannot access to remote files when checking file updates.
Following up #3440, supporting auth.
* 1792 fix remote spec handling and hash calculation (#3440)
(cherry picked from commit 2a2eefe93d81b8d253745b8adb002ab2cb9eee04)
* fix detecting remote file / local file logic while finding the hash file, taking care of IllegalArgumentException for local files.
* add testcase
* [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
* [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
