Gradle Migration

[SmushyTaco]

1. Migrated from Maven to Gradle.
2. Migrated workflows from Maven to Gradle.
3. Added Gradle related files to the .gitignore.
4. Added a Gradle plugin to handle license headers automatically (both ConnectConfigTest.java files and DatabaseLifecycleTest.java were missing headers, this makes sure that never happens again and keeps all headers consistent). See HEADER.
5. Suppressed all PMD and IntelliJ false positive warnings to make Gradle happy while fixing accurate warnings.
6. Used non deprecated alternatives to anything that was deprecated to make Gradle happy.
7. Added quoting to detect_linux_distribution.sh to prevent word splitting which would break the script.
8. Added .gitattributes to normalize line endings and protect the gradle-wrapper.jar.

Closes #164

[SmushyTaco]

@tomix26 after a lot more work than I expected, I've successfully migrated this project from Maven to Gradle. Let me know if I missed anything. I think this should be good to merge.

All dependency versions are also nicely managed in the gradle.properties with links provided for each dependency to easily check what the latest versions for said dependencies are.

[SmushyTaco]

@tomix26 the binaries will still be compiled for JDK 8 but the JDK that runs Gradle will be 17 (or higher) to support the latest Gradle version and to support running its plugins. This doesn't effect compatibility at all, what's shipped will still be JDK 8 (as seen in the gradle.properties). With this change the workflows shouldn't fail immediately. As seen here:

The binary is JDK 8 even though I used JDK 21 to run Gradle. It doesn't change anything, all that matters is the Java version set in the gradle.properties.

Feel free to give the workflows another run. There shouldn't be anymore problems now with the changes I made.

[tomix26]

First off, thank you for the pull request and all your work. I really appreciate it. Your code looks very high-quality.

However, there are far more changes here than we originally agreed upon. This pull request should really only contain changes related to the Maven to Gradle migration. For the other changes, we need to create separate, ideally smaller, pull requests that will be easier to review and manage. When a thousand changes are applied at once, it's difficult to guarantee that nothing breaks.

Also, since this project is a fork of another project, I want to avoid the following types of changes:

• Header changes - because I'm not the original author of all files
• Code formatting changes - I want to preserve as much common code and git history with the original project as possible
• Import formatting changes - this just makes code review harder to follow
• Removing access modifiers in tests - everyone can have different opinions on this, and it doesn't make sense to keep removing and adding them back

I'm also not a big fan of cluttering the code with too many SuppressWarnings annotations, especially for static analysis purposes. So if possible, please try to configure PMD to more closely align with the previous findings.

And the most important topic is compatibility with older Java versions. As I mentioned at the very beginning, tests must run against Java 8 and above. We can't rely on target and release flags because they only ensure binary compatibility of the compiled code, but not compatibility of project dependencies. For example, some dependency might only be binary compatible with newer Java versions. The project compilation will succeed, the resulting JAR will be binary compatible with Java 8, but in reality it won't be possible to run the library on a Java 8 runtime.

Therefore, I'd suggest first verifying whether it's possible in newer Gradle versions to ensure test execution with older Java versions. This is absolutely crucial, without this capability, it doesn't make sense to migrate to Gradle.

[SmushyTaco]

The minimum supported Java version for Gradle is currently Java 17. So if this is the case, then sadly migration won't be possible. I'll close the issue and PR accordingly.

[tomix26]

I'm sorry to hear that. Feel free to create pull requests for the remaining changes that aren't related to the Gradle migration. Just keep in mind that smaller, separate PRs are much easier to review. Thank you.