GH-32: Switch from Gradle to Maven for build tool

[C0urante]

Addresses most #32:

• The build tool is changed from Gradle to Maven
• A parent POM is used to track dependency versions in a single place
• Three submodules are used for the API, Schema Registry schema retriever, and connector, respectively; each with their own child POM
• The integration test script is updated as well to use Maven to run Java code, instead of Gradle
• Adds the Maven release plugin to the POM, which can be used to automatically bump project versions after release

Still remaining is the addition of a Jenkinsfile, which will allow us to fully integrate this project into Confluent's CI/CD pipeline.

This PR targets the earliest feature branch, 1.1.x. If it's approved, I'll merge and then update the later branches as well.

This removes the ability to publish the tarball archive to Maven central; we think Confluent Hub is a good enough release vehicle for now. If someone wants to add that back to the project, though, PRs welcome :)

[mtagle]

Should we add something to the maven central distribution directing people to confluent hub for new versions?

I'm not sure if this is a thing, just thinking

[C0urante]

I'm not sure--I've never seen something like that done. I can think of two potential gotchas that we'd want to avoid if we do decide to try something like that:

1. If we do something like publish a README with no jars or other executable content in place of a "real" release, it'd probably break things if anyone's relying on this as a dependency through automated build tools (such as Maven or Gradle). This isn't totally out of the question if someone's using those to construct, e.g., a Docker image with the connector inside.
2. Anything we publish to Maven Central is there forever. So if we do put out something we'd probably want to give it a version like 2.0.0-NOTICE or 2.0.0-MIGRATION so that it doesn't conflict with a real release if we decide to do one later.

I'm also totally fine if the folks at WePay want to continue pushing to Maven Central; Maven is designed for this kind of thing, after all, so theoretically it shouldn't be too hard to port that logic over to this new build system.

[criccomini]

I am not aware of any standard way to point people at new package spaces in Maven Central. My vote is not to worry about it. Let's just publish in Confluent hub. If it's an issue on our end, we can push to Maven Central as well, but I think it should be fine.

[criccomini]

@C0urante one thing to clarify, does Confluent Hub offer a publicly accessible Maven-compatible repo? We're not using confluent-hub CLI commands. We deploy through an Artifactory cache that fronts Maven Central and other well-formed Maven repos.

[C0urante]

@criccomini Confluent Hub does not offer a Maven mirror; we package connectors into a ZIP archive that includes (among other things) the connector JAR and all of its dependencies. If you'd rather not adjust your tooling to work with that, do you think you could port over the build-a-tarball-and-deploy-to-Maven-Central logic?

[criccomini]

Gotcha. Ok, we'll probably have to implement Maven central publication.

[aakashnshah]

LGTM!