* Modernize, cleanup & fix travis config
* Use Travis “stages” to reduce redundant work
* Checks - pre-test checks (e.g. checkstyle)
* Test - normal test matrix
* Deploy - snapshot artifacts & documents uploads
* Use travis conditionals for deploy stage check
* Deploys from `develop` and `rel/.*`
* Fix filename case issues causing incorrect doc builds
* Properly fixes deploy key setup for gh-pages deploy
* Update README shields
Point them to useful places and make build shield only refer to `develop` branch
* Switch to Gradle build
The switch was made because maven’s support for building a generator library and/or annotation processor in the same project is lacking and causes update problems. Gradle has `buildSrc` and is designed to work with this exact scenario.
### Docker
Docker support has been added to the build scripts. It allows testing against a “default” version of PostgreSQL (currently 11) with normal gradle command.
#### Testing specific or all server versions
Testing against a specific server version can be done using the `testPostgres<version>` family of tasks. Finally, testing against all versions of a server is supported using the `testAllPostgresVersions` task.
### OSGI
The entire build is converted with the exception of `OSGI` packaging. The maven build’s OSGI packaging was already incorrect and produced invalid bundles. This will be added back in an upcoming change that tackles it correctly.
* Fix deprecation use warnings in tests
* Use `unwrap` in tests instead of casting
When attempting to test or retrieve a `PGConnection` or `PGDirectConnection` from a `Connection` all the tests have been made to use `Wrapper.unwrap`. This is to allow the tests to run with wrapped connection (e.g. PGPooledConnection.class).
* Throw exception if DATABASE_URL is invalid
When connecting via DataSource this throws a proper error when the URL is invalid.
* Support JDBC API level tracing
This completes the picture for tracing with the driver; JDBC, SQL & Protocol tracing are all supported and each can be enabled/disabled and routed to files independently.
To support API tracing I added `spy`, a (mostly) auto-generated (via `spy-gen`) JDBC API spying library that wraps & unwraps API objects as they exit/enter the API. The library can actually be used with any driver and is capable of doing quite a bit more than tracing/logging. It’s pretty complete as the entire test suite passes with API tracing enabled; only changes required were to use `unwrap` instead of casting connections (see previous commit).
Since `spy` is generated from the JDBC API interfaces and the JDK is helpfully compiled _without_ parameter names I added `jdbc-api` module that contains the relevant `java.sql` and `javax.sql` interfaces from JDK8 source and compiles them with parameter names enabled; `spy-gen` is run with these classes on the bootclasspath to generate traces with valid parameter names.
* Adds a TOC to generated document
* Orders the settings according to an `order` field in `Setting.Group.Info`
* Adds file names it was generated from to top disclaimer
* Generated DataSource & Docs, Multi module maven
* Generate `AbstractGeneratedDataSource` from global settings groups.
* Includes JavaDoc for each property generated from settings.
* Generate `SETTINGS.md` documentation which details each available parameter and the way(s) it can be provided.
* Switch to multi-module maven project
* Code and Doc generation is from annotation processing which needs to be built before the driver is compiled. It was only acheivable via modules.
* I tried numerous tricks to not have to force moving the files to a subdirectory but none worked.
* Ignore SSL tests when db’s are not created.
* Give DATABASE_NAME empty default
* Fix incremental processing & initialization order
* Fix initialization ordering by generating an initalizer for each factory; replaces the “one giant init” class previously generated.
* `SettingsProcess` works correctly during incremental compiles
* Caches all known factories on each run
* Use the `RetentionPolicy.CLASS` on referenced annotations (i.e. Setting.*)
* Cleanup unused in Setting
* Range docs and validation & easier defaults
* Integer values can specifcy a min and/or max value which are documented and checked at runtime
* All defaults are provided via annotation
* Dynamic defaults are code pasted into the generated initializer
David Wheeler