Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate servers from tapir-loom #3304

Merged
merged 17 commits into from
Nov 8, 2023
Merged

Migrate servers from tapir-loom #3304

merged 17 commits into from
Nov 8, 2023

Conversation

kciesielski
Copy link
Member

@kciesielski kciesielski commented Nov 7, 2023

This PR migrates netty-loom and Helidon Níma servers from https://github.com/softwaremill/tapir-loom/, which is about to become archived.

Builds are reconfigured: a new java axis was added to the matrix, with values of 11 and 21.
The goal is to build and release all modules with JDK 11, except 2 new modules: netty-server-loom and nima-server.
These 2 ought to be built, tested, and released using JDK 21.

One disadvantage of such setup is running compileDocumentation, which has to choose its scope (JDK11) and cannot see these 2 new modules. As a result, mdoc code samples referring to them cannot be compiled.


Please carefully review the publish ci job, so that we avoid turbulences with the next version release, which is supposed to be aware of separate needs for JDK 11/21.


Bonus:

This PR also proposes to switch netty from experimental to stabilising.

@kciesielski kciesielski marked this pull request as ready for review November 7, 2023 15:05
@kciesielski kciesielski changed the title [WIP] Migrate servers from tapir-loom Migrate servers from tapir-loom Nov 7, 2023
@@ -24,7 +24,8 @@ The modules are categorised using the following levels:
| armeria | stabilising |
| finatra | stabilising |
| http4s | stabilising |
| netty | experimental |
| netty | stabilising |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍


import sttp.monad.MonadError

package object loom {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe this should be an id package?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or ... maybe we can put the whole Id interpreter into the main package? only problem, we'd need to compile it using JDK 21. But maybe we can compile using JDK 21 and target 11 bytecode?

Then we could also share the Id alias across netty-loom / nima

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but maybe it's better to keep this separate, I don't know ;)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah let's not overcomplicate for now ;)


import sttp.tapir._

object SleepDemo extends App {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this can be removed now?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or ... move the "demos" to examples?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't seem to add anything more than it's in the docs, so I'll just remove it.

@@ -52,10 +62,13 @@ jobs:
sudo apt-get update
sudo apt-get install libidn2-dev libcurl3-dev
echo "STTP_NATIVE=1" >> $GITHUB_ENV
- name: Enable Loom-specific modules
if: matrix.java == '21'
run: echo "JDK_LOOM=1" >> $GITHUB_ENV
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This env variable makes the project build only jdk21 servers. Checking java version in sbt instead of reading it might cause confusion in local development. For example, I use 21 as my default working JDK, but I still want to build the "JDK11 set". More developers may have such a case. Maybe we should rename the variable to something meaning more "build loom servers only"?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes sense :) add this info to readme in Contributing?

env:
STTP_NATIVE: 1
strategy:
matrix:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hopefully this will work and the two publishes will publish separate jars - no other way to find out than try ;)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, unfortunately there's no nice way to do a dry-run. We could probably make publishArtifacts dependent on some variables, but I'm not sure if it's worth adding complexity.

- java: "21"
target-platform: "Native"
- java: "21"
target-platform: "JS"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so ... we are trying to only include specific axes? maybe we can either (1) use include instead of exlucde, if possible; (2) if not, at least add a comment, what are the desired combinations that should be included

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the hint, somehow I wasn't aware that there's include. Turns out it can be combined with exclude, because exclusions are resolved first, so our rules will become:

        exclude:
          - java: "21"
          - scala-version: "2.12"
            target-platform: "Native"
          - scala-version: "2.13"
            target-platform: "Native"
        include:
          - java: "21"
            scala-version: "2.13"
            target-platform: "JVM"
          - java: "21"
            scala-version: "3"
            target-platform: "JVM"

Looks clearer to me.

@kciesielski kciesielski linked an issue Nov 8, 2023 that may be closed by this pull request
- scala-version: "2.12"
target-platform: "Native"
- scala-version: "2.13"
target-platform: "Native"
include: # Restricted to build only specific Loom-based modules
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

build.sbt Outdated
println("[info] STTP_NATIVE defined, including native in the aggregate projects")
rawAllAggregates
} else {
println("[info] STTP_NATIVE *not* defined, *not* including native in the aggregate projects")
rawAllAggregates.filterNot(_.toString.contains("Native"))
}
if (sys.env.isDefinedAt("JDK_LOOM")) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hm maybe this should be called ONLY_LOOM or sth like that? otherwise it sounds additive

@kciesielski kciesielski merged commit 4772b97 into master Nov 8, 2023
15 checks passed
@mergify mergify bot deleted the netty-loom branch November 8, 2023 12:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Move tapir-nima into tapir
2 participants