feat: publish jvm artifacts

[tomdaffurn]

Closes #2636

[mistermoe]

Summary

This PR introduces the changes needed to publish all jvm artifacts to maven central as part of the pre-existing release github workflow

Note

this is the first of a few PRs to set up jvm artifact publishing with all bells & whistles

JVM Artifacts

• ftl-build-parent
• ftl-build-parent-java
• ftl-build-parent-kotlin
• ftl-java-runtime
• ftl-java-runtime-deployment
• ftl-java-runtime-parent
• ftl-jvm-bom
• ftl-jvm-parent
• ftl-jvm-runtime
• ftl-jvm-runtime-deployment
• ftl-jvm-runtime-integration-tests
• ftl-jvm-runtime-parent
• ftl-jvm-test-framework
• ftl-kotlin-runtime
• ftl-kotlin-runtime-deployment
• ftl-kotlin-runtime-parent

Changes

• added maven_settings.xml which configures authentication for Maven to access different artifact repositories
• added profile that can be used to sign artifacts during the build process. It activates the sign-maven-plugin, which automatically signs the project's artifacts. This is required when
  deploying to Maven Central or other repositories that mandate signed artifacts for security and authenticity verification. Activate this profile when you need to create signed releases, usually in conjunction with the deployment to public repositories.
• added profile used to deploy artifacts to Maven Central via OSSRH (OSS Repository Hosting). It configures the nexus-staging-maven-plugin for automated deployment and release, and sets up the distribution management for both snapshot and release repositories. Activate this profile when deploying open-source projects to Maven Central.
• specified snapshot and release repositories
• Included groundwork for mirroring all artifacts and caching all third party dependencies in artifactory in a subsequent PR
• added job to pre-existing release github workflow to publish all jvm artifacts for each version bump

Considerations

Move jvm artifact publishing into a separate github workflow

benefits of this would be the ability to publish artifacts independent of releases. this can be helpful in scenarios where:

• everything in the release ci passes except for this
• publishing *-SNAPSHOT artifacts for consumption is desired
• running this workflow in isolation and on demand is desired

We could set it up such that successful completion of the release workflow triggers a publish-jvm-artifacts workflow

Mirror artifacts and third party deps in artifactory

Other JVM artifacts published at TBD do this today for redundancy, availability, and caching

[tomdaffurn]

Was the Java doc not needed @mistermoe? I was getting errors from Sonatype without it.

[mistermoe]

Oh really? We should add it back in then. I only built the artifacts locally which worked fine. Didn't try re-publishing.

I removed bc we aren't using dokka anywhere afaict

[stuartwdouglas]

I don't think we want these in the plugins section, they should be in a profile, e.g. there is not need to generate source artifacts in a development build.

[tomdaffurn]

Great point, I added release profile to group signing and source jarring

[stuartwdouglas]

Shouldn't this be in the .settings.xml? I also don't understand what the use case is here, won't the TBD artifactory pull them down from central once they have been released?

[stuartwdouglas]

In general this is a bad idea to put TBH repos into a publicly published pom. This will mean that projects consuming this pom will end up with these repositories in their repo list. If we really need them they should be in a
settings.xml file.

[mistermoe]

@stuartwdouglas it may be best to connect with @ALRubinger as he paved the way here for other jvm artifacts at tbd. Take a look at web5-kt or tbdex-kt for reference.

No real opinions from my pov especially with limited jvm experience. Happy to do whatever you think makes sense.

[stuartwdouglas]

I have moved it to a settings.xml profile for now.