Add troubleshooting in local development (#2344)

Author: Anthony Hillairet

docs/architecture/airbyte-specification.md

@@ -3,7 +3,7 @@
 ## Key Takeaways
 
 * The specification is Docker-based; this allows a developer to write a connector in any language they want. All they have to do is put that code in a Docker container that adheres to the interface and protocol described below.
-  * We currently provide templates to make this even easier for those who prefer to work in python or java. These templates allow the developer skip any Docker setup so that they can just implement code against well-defined interfaces in their language of choice.
+  * We currently provide templates to make this even easier for those who prefer to work in python or java. These templates allow the developer to skip any Docker setup so that they can just implement code against well-defined interfaces in their language of choice.
 * The specification is designed to work as a CLI. The Airbyte app is built on top of this CLI.
 * The specification defines a standard interface for implementing data integrations: Sources and Destinations.
 * The specification provides a structured stdout / stdin message passing standard for data transport.
@@ -217,7 +217,7 @@ For the sake of brevity, we will not re-describe `spec` and `check`. They are ex
 
 * All messages passed to and from connectors must be wrapped in an `AirbyteMesage` envelope and serialized as JSON. The JsonSchema specification for these messages can be found [here](https://github.com/airbytehq/airbyte/blob/master/airbyte-protocol/models/src/main/resources/airbyte_protocol/airbyte_protocol.yaml).
 * Even if a record is wrapped in an `AirbyteMessage` it will only be processed if it appropriate for the given command. e.g. If a source `read` action includes AirbyteMessages in its stream of type Catalog for instance, these messages will be ignored as the `read` interface only expects `AirbyteRecordMessage`s and `AirbyteStateMessage`s. The appropriate `AirbyteMessage` types have been described in each command above.
-* **ALL** actions are allowed to return `AirbyteLogMessage`s on stdout. For brevity, we have not mentioned these log messages in the description of each action, but they are always allowed. An `AirbyteLogMessage` wraps any useful logging that the connector wants to provide. These logs will written to Airbyte's log files and output to the console.
+* **ALL** actions are allowed to return `AirbyteLogMessage`s on stdout. For brevity, we have not mentioned these log messages in the description of each action, but they are always allowed. An `AirbyteLogMessage` wraps any useful logging that the connector wants to provide. These logs will be written to Airbyte's log files and output to the console.
 * I/O:
   * Connectors receive arguments on the command line via JSON files. `e.g. --catalog catalog.json`
   * They read `AirbyteMessage`s from stdin. The destination `write` action is the only command that consumes `AirbyteMessage`s.

docs/contributing-to-airbyte/developing-locally.md

@@ -184,3 +184,14 @@ Sometimes you'll want to reset the data in your local environment. One common ca
    docker-compose --env-file .env.dev -f docker-compose.yaml -f docker-compose.dev.yaml up -V
   ```
 
+## Troubleshooting
+
+### `gradlew Could not target platform: 'Java SE 14' using tool chain: 'JDK 8 (1.8)'.`
+
+Somehow gradle didn't pick up the right java version for some reason.
+Find the install version and set the `JAVA_HOME` environment to point to the JDK folder.
+
+For example:
+```
+env JAVA_HOME=/usr/lib/jvm/java-15-openjdk ./gradlew  :airbyte-integrations:connectors:your-connector-dir:build
+```