* Add support for using Spring HATEOAS to add links in the spring generator.
* Ensure that Spring HATEOAS links appear last in the JSON serialisation of objects.
* A couple of changes following code review:
1. Make sure the @JsonPropertyOrder annotation is only used when the jackson library is being used since it's a part of the jackson library.
2. Make sure to include the Spring HATEOAS dependency in the pom file for the spring-cloud and spring-mvc generators when the hateoas option is enabled.
* Don't order the json properties since there's no requirement for the links to be last.
* Remove unnecessary import.
* Allow specifying/overriding the parent in the pom file for Java and Spring generators.
* Don't add extra whitespace to the pom file when the parent isn't overridden.
* Remove accidentally added white space.
* renmae Go post process file env variable
* add back samples/client/petstore/c/libcurl.licence
* keep go samples up-to-date
* update go petstore samples
* update go samples without formatting
* copy from go-server and add go-gin-server generator
* change the templates for the gin
* fix warnings of the golint tool
* fix the path of script
* add samples
* delete unnecessary comments (#1048)
* make the help message more appropriate (#1048)
* fix the link address format (#1048)
* minor improvement
Updates some confusing wording, specifies naming conventions, and links
to external `new.sh` for contributed templates (rather than modified
templates).
* Expanding customization docs
As a new user I was very confused on how to either modify, override or create a new library. The existing docs were brief and had requirred knowledge that new users will not have, and it took a lot of trial and error to make progress.
Also the wording seemed off. It kept talking about "client" when this project creates more than just clients, used "language" when some templates are not a language, and used library to mean a few seeminly different things. I've tried to consolidate the wording around "template" and "codegen".
The codegen is the Java code, and then you give it a "name" which is used for the template. That's the template folder it will live in, so it seems to work.
Feel free to use this as a base and edit it out, but this will all make a lot more sense to beginners. :)
* update release version to 3.0.0
* comment out ensure-up-to-date during the release
* add release note
* clean up
* clean up links
* add release note for 3.0.0
* update release note
* update release note
* update version for gradle plugin before release
* [gradle-plugin] Initial commit
* Clarify comments on file constraints
When a user sets the models, apis, or supportingFiles environment
variables, any one of these being set disables generation for the other
two. This could be confusing to users, so I've added some clarification
text in the comments for these properties.
In addition, I've cleaned up the extension on
Property.ifNotEmpty, to avoid using Suppress annotations where it's not
necessary. The change creates a local variable of type T?, allowing
Kotlin to track the variable's nullable state at compile time.
* Move gradle plugin under modules
* Move kt files under kotlin source set. Add sample.
* [gradle] map-like options as maps
* Add tests for gradle validate task
* Apply gradle plugin to mvn install phase
* [gradle] Testing remaining gradle tasks
* Add gradle plugin to the integration doc
* Update gradle plugin README with task options
* Gradle readme formatting
* add question and anaswer section
* add project URL to the license
* Use relative path for link between pages
* Reword some sentences, remove we/they style
