* [Bugfix][Maven-Plugin] Bugfix for remote input specs with parameters
If the inputSpec was a web address that contained parameters, code generation would fail, because the filepath would contain illegal characters, since the code inside the if-block would be skipped. A side effect of this was, that in the log and in the filename in linux the parameters would be leaked, which could potentially sensitive information like Gitlab Access Tokens
* [Test][Gradle Plugin] Update GenerateTaskDslTest.kt
Extended the Test for testing remote inputSpecs with urlParams, a case that caused problems in the maven plugin.
* added intellij-codestyle.xml and sample of it being applied to some java code-gen classes
* code-format changes ONLY
* few more format changes since last merge with master
* applied code-style to all java one last time
* added test with external-ref ("external dependency" installed before actual usage)
* fixed test with resource on classpath
added test with resource on classpath with external-ref.
Test with profile 'resource' was wrong as it took JAR into account, but there was no 'petstore.yaml' on classpath.
* Remove dependency scan and do not modify inputSpec provided by user
It is still possible to provide JARs as inputSpec, however the user has to provide it by hand.
Providing dependencies in plugin section still allows correct inputSpec resolution on classpath.
* Ensure temp directories are deleted after test execution
* Implement test that external $ref changes are reflected in checksum
* Generate hash checksum from actual resolved spec instead of inputSpec file
Otherwise regeneration will not happen when skipIfSpecIsUnchanged is enabled,
although formally the spec content has changed.
Fixes#4512 and #16489
* Use try-with-resources to ensure stream is closed properly on exit
* Fix deprecation warning on SimpleLocalRepositoryManagerFactory no-arg constructor
* Apply minor code cleanup
- use fluent setters where possible
- remove undocumented @throws from JavaDoc
- use List.of() instead of Arrays.asList() for single-element-collection
(more memory efficient)
- fix some grammar issues in comments and JavaDoc
* Use non-blocking java.nio API for file existence checks
* Revert "Revert back to junit4 (#18786)"
This reverts commit 2471ba2d2e.
* Make junit engine execute TestNG test cases
* Fix failing test and use tempDir's for test code generation
* Make test fail with helpful info in case generator throws exception
* Suppress error output from TestUtils
* Remove transitive junit4 dependency
* Sync guava-testlib version with guava version
* Add hint regarding alternative for guava-testlib's FakeTicker
* Added support for <inputSpec/> arguments of JAR URLs.
E.g., jar:jar-specific-uri!/spec.yml.
* Resolve and search COMPILE dependencies for inputSpec resource.
* Added test cases for openapi-generator-maven-plugin:generate input
specifications:
* URLs of the form jar:jar-specific-uri!/spec.yaml
* Resources on the compilation classpath
in addition to the existing FILE test case.
* Check for inputSpecFile existence
else it is a remote URL && url is not empty
* replaced deprecated usage
* use Unix separators when on win-os
* example with jar inputSpec
* Comment not required anymore
Was introduced with #7587 could be removed with #10544
* referenced same maven version
these artifacts are referenced by same ${project.version} in https://github.com/apache/maven/blob/master/pom.xml
* updating maven dependencies to 3.9.6
---------
Co-authored-by: Allen D. Ball <ball@hcf.dev>
* Adds Collapse Spec Optionss to Maven Plugin
* Adds a collapsedSpec option to the maven plugin that produces a single-file representation of the spec in the output directory.
* Adds a includeCollapsedSpecInArtifacts option to the maven plugin that adds the collapsed spec file to the maven artifacts.
* Address Feedback Round 1
* Adds the new options to the maven plugin README.md.
* Fixes Unit Tests
* Corrects the casing of one of the schema files that was causing the tests to fail.
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'
