* Support additionalproperties and more.
- Upgrade to TypeScript 2
- Use type definition from npm instead of typings, typings is deprecation
- Use Enum instead of String Literal Types
- Use typescript es6 lib for target es5
- Support additionalproperties
- Support JSDoc
- Add snapshot and npmRepository option
- Update typescript-fetch run script for linux
- Create typescript-fetch run script for windows
* Update and fix
- Fix circle run script
- Fix duplicate query parameter
* Rename typescript-fetch folder to lowercase
* Fix for review and update new line end of file
* Fix end of file
* rename script to {lang}-petstore-all.sh and fix test
* Fix override query string
https://stackoverflow.com/a/7517673/1077943
The [java8 doclint](http://openjdk.java.net/jeps/172) rejects unescaped
HTML chars such as `<`, making some generated clients unbuildable with
java8. Seems a few property descriptions were using the `{{{` instead
of `{{` preventing those HTML chars from being escaped properly.
* Closes#5863
The "dateLibrary" option for java, sadly, sets a mustache value "java8". This change updates this so that "java" in the mustache
libraries means what it should mean - use all java8 classes. In this case, there's no need for the third party Base64 library
as java8's JDK has this built in. In my view, the "dateLibrary" should be deprecated but that should be a separate PR.
* Closes#5954
built and ran tests/samples
* Closes#5863
The "dateLibrary" option for java, sadly, sets a mustache value "java8". This change updates this so that "java" in the mustache
libraries means what it should mean - use all java8 classes. In this case, there's no need for the third party Base64 library
as java8's JDK has this built in. In my view, the "dateLibrary" should be deprecated but that should be a separate PR.
* updated samples
* fixed tests for new CLI java8
* regenerated samples after master merge
* oops - left in an end tag after master merge
* rerun checks
* rerun checks
* Changing QBuffer to use a QByteArray solves the issue for me since there is no real use-case for using a QBuffer.
Documentation of QT5 states:
QBuffer::QBuffer(QByteArray *byteArray, QObject *parent = Q_NULLPTR)
Constructs a QBuffer that uses the QByteArray pointed to by byteArray as its internal buffer, and with the given parent. The caller is responsible for ensuring that byteArray remains valid until the QBuffer is destroyed, or until setBuffer() is called to change the buffer. QBuffer doesn't take ownership of the QByteArray.
Since the variable “request_content” is allocated on the stack, this is clearly wrong and a bug. The construction of QBuffer is designed this way so that whenever you write to the buffer, it is also written to the byte array that it is pointing to
* Add a retro-compatible solution based on QNetworkAccessManager SourceCode
* update samples
* Fix issue with buffered sink handling in okhttp
Fixes unexpected end of stream exceptions when using the okhttp-gson library
and making asynchronous calls.
* update petstore samples for okhttp-gson
$ ./bin/java-petstore-okhttp-gson.sh
$ ./bin/security/java-petstore-okhttp-gson.sh
* WIP: trigger ci
* remove trailing space in cpprest, update samples
* remove unused pom.xml in go pestore
* fix broken links in php api doc by fixing baseType
* fix csharp api doc
* fix php examples
* fix examples for abstract php generator
