Feature/maven artifacts - #183
Conversation
|
|
||
| - uses: actions/setup-java@v4 | ||
| with: | ||
| java-version: '17' |
There was a problem hiding this comment.
Maybe better to use 21, since it's the latest LTS.
There was a problem hiding this comment.
21 doesn't seem to work currently, so that could be a later improvement.
|
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 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. |
|
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. 🙂 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. 😬) |
| [thheller/shadow-cljs "2.20.14"]] | ||
| :source-paths ["src/main/cljs" "src/main/cljc" "src/test/cljs" "src/test/cljc"]}}) | ||
| :source-paths ["src/main/cljs" "src/main/cljc" "src/test/cljs" "src/test/cljc"]} | ||
| :uberjar {:uberjar-exclusions [#"org/slf4j"]}}) |
There was a problem hiding this comment.
This is a transitive dependency from "org.bitbucket.b_c/jose4j", which causes an issue with my demoproject. With this exclusion, I can at least build and run my demo project successfully, but there's a huge amount of debug log noise coming from Jarl, which I haven't been able to change yet.
Ideally, I'd want to get it to work with Logback, so that I can configure something like this in my application.properties file:
logging.level.com.fleskesvor.auth_server=debug
logging.level.by.borge.jarl=info
to change the log level of my own code and Jarl independently. Actually, "info" should even be the default log level for Jarl, but even so, it would be nice to be able to configure its level easily at runtime. I'm not very familiar with this stuff, so I'll need to explore what my options are. Some quick reading suggests that log level is set at compile time with Timbre, but that can't be right.
|
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. 😉 I think there are mainly two things I need feedback on:
|
|
As a starting point, maybe a release workflow with a simple versioning scheme could look something like this for commits on the main branch:
This will require some way to set versions in A future improvement could be to add some manual control to versioning, e.g.:
Thoughts? |
2 participants
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.cljandapi/build.gradle, and if both packages are published successfully, then bump snapshot versions and git commit+push that.