Morph MORPH
SIGN IN SIGN UP
OpenAPITools / openapi-generator UNCLAIMED

OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec (v2, v3)

0 0 5 Java
Normal View History Raw
Feature: Experimental Handlebars support (rienafairefr) (#2657) * 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.
2019-04-25 21:52:50 -04:00
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<parent>
<artifactId>openapi-generator-project</artifactId>
<groupId>org.openapitools</groupId>
Release versioning helper script(s) (#3110) * 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
2019-06-24 18:22:10 -04:00
<!-- RELEASE_VERSION -->
Prepare v7.20.0 release (#22738) * Revert "v7.19.0 release (#22732)" This reverts commit ff400e9a31f0152322d32ebe888c8591a8401392. * prepare v7.20.0 release * update samples * update doc
2026-01-20 03:13:58 +08:00
<version>7.20.0-SNAPSHOT</version>
Release versioning helper script(s) (#3110) * 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
2019-06-24 18:22:10 -04:00
<!-- /RELEASE_VERSION -->
Remove unused test dependencies `org.reflections` & `maven-rewrite` (#18798) * Specify exact relative path to parent pom.xml * Remove org.reflections from the test stack * Remove unused parameter * Remove unused method * Fix raw use of parameterized variable warning * Use Files.readString instead of converting raw bytes * Add test coverage for TestUtils.validatePomXmlFiles(List) * Reimplement TestUtils.validatePomXmlFiles(List) with Jackson XML mapper * Remove maven-rewrite dependency
2024-06-01 10:42:26 +02:00
<relativePath>../../pom.xml</relativePath>
Feature: Experimental Handlebars support (rienafairefr) (#2657) * 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.
2019-04-25 21:52:50 -04:00
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>openapi-generator-core</artifactId>
<name>openapi-generator-core</name>
<url>https://github.com/openapitools/openapi-generator</url>
[core] GeneratorSettings, WorkflowSettings, and cleanup in CodegenConfigurator (#2946) * 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
2019-06-07 13:07:52 -04:00
[ci][test] Modifications to static analysis contribution via Tomasbjerre (#5116) * Spotbugs, PMD and Checkstyle #33 * Reducing Spotbugs effort to min #33 * Also using project.parent.basedir and avoiding relative paths in pom files. * Filtering out samples. * Move PMD/Spotbugs to static-analysis profile This moves the static-analysis checks to a standalone profile. Core contributors may run static analysis with: ``` mvn -Pstatic-analysis install ``` The analysis is separated from default functionality to reduce impact to community contributions. SpotBugs/PMD may add a non-trivial amount of time to builds on some machines. Co-authored-by: Tomas Bjerre <tomas.bjerre85@gmail.com>
2020-01-26 12:45:41 -05:00
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<configuration>
<configLocation>${project.parent.basedir}${file.separator}google_checkstyle.xml</configLocation>
</configuration>
</plugin>
</plugins>
</build>
[core] GeneratorSettings, WorkflowSettings, and cleanup in CodegenConfigurator (#2946) * 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
2019-06-07 13:07:52 -04:00
<dependencies>
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
Improve version management, update dependencies, remove unused dependencies (#10544) * Move verion properties to main pom.xml * Sort properties and remove duplicates * Use properties for known versions * Deduplicate versions of maven plugins * Deduplicate wagon dependencies * Deduplicate maven targer and source properties * Explicitly set testng version * Remove property used once * Sort lines * Standardise name of maven version properties * Upgrade maven-surefire-plugin * Comment out jackson-datatype-jsr310 * Comment out com.fasterxml.jackson.core:jackson-core:jar:2.10.2:compile * Remove commented out dependencies * Rename maven param name * Remove org.hamcrest:java-hamcrest:jar:2.0.0.0:test * Bump jacoco * Upgrade guava, replace deprecated or removed api with vanilla java * Bump jmustache.version * Bump jackson.version * Bump jackson.version and mockito * Bump testng * Bump wagon-ssh-external.version * Downgrade jmustache * Bump spring boot version and add junit * Bump maven in wrapper * Bump apache libs * Bump dependencies * Revert checkstyle bump
2021-10-13 07:46:01 +01:00
<version>${guava.version}</version>
[core] GeneratorSettings, WorkflowSettings, and cleanup in CodegenConfigurator (#2946) * 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
2019-06-07 13:07:52 -04:00
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
Improve version management, update dependencies, remove unused dependencies (#10544) * Move verion properties to main pom.xml * Sort properties and remove duplicates * Use properties for known versions * Deduplicate versions of maven plugins * Deduplicate wagon dependencies * Deduplicate maven targer and source properties * Explicitly set testng version * Remove property used once * Sort lines * Standardise name of maven version properties * Upgrade maven-surefire-plugin * Comment out jackson-datatype-jsr310 * Comment out com.fasterxml.jackson.core:jackson-core:jar:2.10.2:compile * Remove commented out dependencies * Rename maven param name * Remove org.hamcrest:java-hamcrest:jar:2.0.0.0:test * Bump jacoco * Upgrade guava, replace deprecated or removed api with vanilla java * Bump jmustache.version * Bump jackson.version * Bump jackson.version and mockito * Bump testng * Bump wagon-ssh-external.version * Downgrade jmustache * Bump spring boot version and add junit * Bump maven in wrapper * Bump apache libs * Bump dependencies * Revert checkstyle bump
2021-10-13 07:46:01 +01:00
<version>${slf4j.version}</version>
[core] GeneratorSettings, WorkflowSettings, and cleanup in CodegenConfigurator (#2946) * 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
2019-06-07 13:07:52 -04:00
</dependency>
[core] Initial implementation of a validation framework in core (#3183) * Initial implementation of a validation framework in core * Print surefire summary (helps evaluate errors) * Bump versions: surefire plugin,jmockit * Depend on jmockit within maven-surefire-plugin which requires it
2019-06-24 18:24:50 -04:00
<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
Improve version management, update dependencies, remove unused dependencies (#10544) * Move verion properties to main pom.xml * Sort properties and remove duplicates * Use properties for known versions * Deduplicate versions of maven plugins * Deduplicate wagon dependencies * Deduplicate maven targer and source properties * Explicitly set testng version * Remove property used once * Sort lines * Standardise name of maven version properties * Upgrade maven-surefire-plugin * Comment out jackson-datatype-jsr310 * Comment out com.fasterxml.jackson.core:jackson-core:jar:2.10.2:compile * Remove commented out dependencies * Rename maven param name * Remove org.hamcrest:java-hamcrest:jar:2.0.0.0:test * Bump jacoco * Upgrade guava, replace deprecated or removed api with vanilla java * Bump jmustache.version * Bump jackson.version * Bump jackson.version and mockito * Bump testng * Bump wagon-ssh-external.version * Downgrade jmustache * Bump spring boot version and add junit * Bump maven in wrapper * Bump apache libs * Bump dependencies * Revert checkstyle bump
2021-10-13 07:46:01 +01:00
<version>${testng.version}</version>
[core] Initial implementation of a validation framework in core (#3183) * Initial implementation of a validation framework in core * Print surefire summary (helps evaluate errors) * Bump versions: surefire plugin,jmockit * Depend on jmockit within maven-surefire-plugin which requires it
2019-06-24 18:24:50 -04:00
<scope>test</scope>
</dependency>
[core] GeneratorSettings, WorkflowSettings, and cleanup in CodegenConfigurator (#2946) * 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
2019-06-07 13:07:52 -04:00
</dependencies>
[ci][test] Modifications to static analysis contribution via Tomasbjerre (#5116) * Spotbugs, PMD and Checkstyle #33 * Reducing Spotbugs effort to min #33 * Also using project.parent.basedir and avoiding relative paths in pom files. * Filtering out samples. * Move PMD/Spotbugs to static-analysis profile This moves the static-analysis checks to a standalone profile. Core contributors may run static analysis with: ``` mvn -Pstatic-analysis install ``` The analysis is separated from default functionality to reduce impact to community contributions. SpotBugs/PMD may add a non-trivial amount of time to builds on some machines. Co-authored-by: Tomas Bjerre <tomas.bjerre85@gmail.com>
2020-01-26 12:45:41 -05:00
<profiles>
<profile>
<id>static-analysis</id>
<build>
<plugins>
<plugin>
<groupId>com.github.spotbugs</groupId>
<artifactId>spotbugs-maven-plugin</artifactId>
<configuration>
<excludeFilterFile>${project.parent.basedir}${file.separator}spotbugs-exclude.xml</excludeFilterFile>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
</plugin>
<plugin>
<groupId>se.bjurr.violations</groupId>
<artifactId>violations-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
</profile>
</profiles>
4.0.0 release (#2878) * remove snapshot version * update readme * undo changes to example * revert apache maven version * update gradle property
2019-05-13 20:56:47 +08:00
</project>
Reference in New Issue Copy Permalink