valitydev/openapi-generator
14
0
Fork 0
mirror of https://github.com/valitydev/openapi-generator.git synced 2024-11-06 10:35:25 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
56f298a0b4
openapi-generator/docs/roadmap.md
Jim Schubert 6fe9a52229 [feat][docs][website] Initial docusaurus based site (#1770) 
* Iniital docusaurus based site

* Remove error about default local being used by String.format

* Change pinned users to represent global presence rather than alphabetical order pinning

* Include generator indexes in ensure-up-to-date (docusaurus site and /generators/README)

* Add Font Awesome attribution footer

* Remove feature callout until it is completed

* Include NPM try it out section

* Improve "Getting Started" type docs

* Include new custom template documentation

* Updating templating and customization docs

* Add vendor extension docs

* Cleanup templating page(s).

* Move users to yaml file for easy edit.

* travis configuration, and baseUrl mods to image URLs

* [docs] Migrate FAQ, release summary  from wiki

FAQ has been split into multiple smaller documents to better categorize
and allow users to find what they're looking for (in docs folder or in
new website).

Release summary information (versioning strategy and cadence) has been
migrated from the Wiki and clarified a bit.

Also adds copy button for all code snippets in website.

* Copy current contributing/code of conduct to website

* [docs] Creating a new generator
2019-01-18 17:39:33 +08:00

4.2 KiB
Raw Blame History

id title
roadmap Roadmap

This document lists short-term, medium-term, and long-term goals for the project.

NOTE

These are goals, not necessarily commitments. The sections are not intended to represent exclusive focus during these terms. For example, when you start at a college or university you may have a long-term goal to graduate and a short-term goal to find a job for supplemental income. We will similarly work toward many of our medium-term and long-term goals in the near future as we move toward meeting our short-term goals.

Short-term

Usability, stability, and marketing.

Short term are focused on improving contributor and user productivity (part of this is getting the word out).

  • CLI improvements
    • Search functionality (e.g. what generators support retrofit, what generators are available for kotlin)
  • Build automation improvements
  • Discuss consolidating current third-party build systems
  • Investigate custom docker containerization for prepared build environments
  • Automated release stability
  • General
  • OAS3.0 features support: anyOf, oneOf, callbacks, etc
  • Consider opt-in telemetry about generators being used, limited to a counter of invocations by generator name). This would allow us to make prioritization decisions based on statistics.
  • Code clean up
  • Documentation
  • Static pages, preferably on gh-pages, devoted to each generator
  • Explain generator options
  • Centralized docs on generated code usage/examples/configuration

Medium-term

Feature set, well-defined API (code and templates), and extensibility improvements.

API

  • Typed representation of the model bound to our templates. As it is, everything is treated an an Object, and this can lead to changes in the interface which might be unexpected from the template perspective.
  • Feature set (potential generators to add; not an exhaustive list)
    • Azure functions (node.js, server)
    • Finagle HTTP Client (Scala, client)
    • Finagle Http Server (Scala, server)
    • Finatra (Scala, server)
    • Kotlin Spring MVC/Springboot (server)
    • C++ Server, any framework (server)

General

  • Migrate from Maven to Gradle
  • Java 9+ support
  • Feature set (other options to investigate)
  • SPI plugins
  • Customizable templating engines (handlebars support)
  • Unit-testing templates (to previously mentioned explicit type as an interface to the template)
  • Reduce coupling
  • Make types extending CodegenConfig become the generation entrypoint
  • Allow current CodegenConfig types to define templating engine
  • Allow current CodegenConfig types to modify workflow (currently encapsulated in DefaultGenerator and tightly coupled to the template engine
  • Clearer reuse of "language" features, outside of "generator" types. That is, rather than enforcing polymorphic sharing of "language" which currently allows the super type to redefine framework-specific mapping functionality, generators could compose one or more language support types.
  • Define template deprecation/removal process

Long-term

Expanding tooling offered, integrations, potentially SaaS offering to partially fund efforts.

  • Generator UI wrappers
    • Move jimschubert/intellij-swagger-codegen plugin under the org, and rename
    • Look into an Eclipse UI wrapper around the generator
    • Look at Visual Studio Code (and/or Atom, sublime text) integration
  • Provide a native GUI for viewing/editing specs. Most tools are currently geared toward developers, but often times it may be non-technical business users who are interested in an API.
  • A paid service (SaaS) for generation may be enticing for some users. Such a service would allow for statistics (mentioned earlier in telemetry)
  • Additional tools
  • node.js build system(s) integration (grunt/gulp/webpack/etc)
  • ruby gem
  • others (which may require previously mentioned SaaS API)