Feature/maven artifacts

[fleskesvor]

Adds workflow to build and deploy Jarl Core + API to GitHub Packages.

Unfortunately, it's not possible to install Maven packages from GitHub Packages without authentication, but it's not a major inconvenience, in my opinion: https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-apache-maven-registry#authenticating-with-a-personal-access-token

This doesn't fix release versioning + snapshot bumping, and I'm not sure how to do that in a tidy way in a "polyglot" project. Maaaaybe add an initial job that sets release versions in core/project.clj and api/build.gradle, and if both packages are published successfully, then bump snapshot versions and git commit+push that.

[fleskesvor]

Added a new commit which produces a fat jar of the API package, so that core no longer needs to be published, and API doesn't need to rely on the Clojure repository (or GitHub Packages). That's a whole lot of stuff though, so not sure if it's ideal.

There's also the issue of versioning, which hasn't been fixed, but this way, versioning of core doesn't need to be part of this workflow anyway, and API could be versioned separately (just make "core version" a separate variable in build.gradle).

I'm also having some issues with a conflict between Timbre and Logback in my demo application (https://gitlab.com/fleskesvor/auth-server), and no seemingly easy way to configure log level or format with Timbre (and the default level (debug) is very noisy), but that's a separate issue.

[anderseknert]

Hey! And thanks for this 👍 I'm a bit swamped this week but I'll review as soon as I find some time.

[fleskesvor]

Hey! And thanks for this 👍 I'm a bit swamped this week but I'll review as soon as I find some time.

No problem. :slightly_smiling_face: It's very much a work in progress, and it's not even usable to me at the moment. (I'm starting to remember why I made so many hacks to use Jarl in my project now. :grimacing:)

[anderseknert]

Hey there! I just realized I forgot to check back :) What's your current status here? Let me know if there's anything I can help you with.

[fleskesvor]

Hey there! I just realized I forgot to check back :) What's your current status here? Let me know if there's anything I can help you with.

No problem! I forgot too. :wink:

I think there are mainly two things I need feedback on:

1. Will the exclusion of "org/slf4j" in the uberjar cause issues with current users of Jarl? I added this to resolve a conflict with my demo project, as mentioned in an earlier comment.

2. I haven't thought of a good way to handle automatic versioning of the Maven package, and just publishing 0.1.0-SNAPSHOT with every commit on the main branch doesn't seem like a good idea. Do you have any thoughts on how to handle this?

[fleskesvor]

As a starting point, maybe a release workflow with a simple versioning scheme could look something like this for commits on the main branch:

1. version in core/project.clj is set to a release version automatically (i.e. currently 0.1.0)
2. core is built
3. version in api/pom.xml is derived from version in core/project.clj (or core/pom.xml (they are the same, so whatever is easier))
4. api is built
5. api package is published as a Maven artifact to GitHub packages (https://maven.pkg.github.com/borgeby/jarl)
6. version in core/project.clj is bumped to the next patch snapshot version (i.e. currently 0.1.1-SNAPSHOT)
7. version in api/pom.xml is derived from version in core/project.clj / core/pom.xml

This will require some way to set versions in core/project.clj and api/pom.xml, but that's probably not too difficult.

A future improvement could be to add some manual control to versioning, e.g.:

1. running the workflow on git tags on the main branch, and derive semver from the git tag
2. running the workflow on commits matching a prefix and containing "major", "minor" or "patch" in the commit message
3. using a GitHub bot to bump versions somehow
4. running the workflow on a workflow dispatch

Thoughts?