Refactor build script.

[overcat]

Changelog:

• No longer provide shadow jar.
• The jar provided by default does not include third-party dependencies, when you use Gradle and Maven, third-party dependencies should be automatically downloaded.
• Provided an uber jar, which includes the third-party dependencies used.
• Bump Gradle from 7.4.1 to 8.3
• Migrate the build script to kotlin
• Upgrade the JDK version used for building to JDK 17.
• Bump Gradle plugins

[sreuland]

what will the artifact classifier be for the uber jar? Assuming the non-uber jar will be the artifact with classifier=jar correct?

[overcat]

Their classifiers are '', 'uber', and 'javadoc'.

[overcat]

Users can add them in three different ways.

    implementation("com.github.stellar:java-stellar-sdk:0.41.0")
    implementation("com.github.stellar:java-stellar-sdk:0.41.0:uber")
    implementation("com.github.stellar:java-stellar-sdk:0.41.0:javadoc")

[sreuland]

awesome, would you mind just adding a note for this in pending section in the CHANGELOG.md, so users can choose between the legacy behavior with dependency of com.github.stellar:java-stellar-sdk:0.41.0:uber or if they want 'thin' jar and transitive dependency management then com.github.stellar:java-stellar-sdk:0.41.0

[overcat]

I have updated the changelog, but ubar jar is different from the previous shadow jar in that it does not relocate third-party dependencies.

[sreuland]

this looks great, just wondering about how to describe this in CHANGELOG.md, its not necessarily breaking, for many sdk users, the dependencies should resolve at build time, but we should state if they have any explicit deps declared against same nested dependency tree as this project, then they may run into runtime classloader issue to be aware of?

[overcat]

this looks great, just wondering about how to describe this in CHANGELOG.md, its not necessarily breaking, for many sdk users, the dependencies should resolve at build time, but we should state if they have any explicit deps declared against same nested dependency tree as this project, then they may run into runtime classloader issue to be aware of?

I think they may encounter dependency conflicts, but I believe this can be resolved. Additionally, based on my testing, I successfully imported the thin jar from jitpack into an android template project without any conflicts.