You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It turns out that Tapir also uses these exact same constructors but Tapir is in its own package. Tapir recently added Pekko HTTP support but didn't add Scala 3 support for Pekko HTTP (softwaremill/tapir#3114).
Should we start making these constructors (see #178) public?
If so, should we backport to 1.0.1 even though this will probably affect binary compatibility?
Adding a hacky org.apache.pekko scoped util class to Tapir should allow a workaround that can create Content-Length/Content-Type instances.
Looks like the Tapir team have worked around this issue so that means we don't need to make an immediate change - but it might still be worth considering whether to make the constructors public.
We shouldn't just make something public that was made private intentionally (i.e. probably because we want to uphold some invariants). That said, if there's a need for a public API, we can look into what's needed and add that.
For some reason, Scala 2 seems to allow public access to package private constructors but Scala 3 enforces it.
We also had to relax the scope on 2 constructors to allow pekko-connectors to compile with Scala 3.
#178
It turns out that Tapir also uses these exact same constructors but Tapir is in its own package. Tapir recently added Pekko HTTP support but didn't add Scala 3 support for Pekko HTTP (softwaremill/tapir#3114).
Should we start making these constructors (see #178) public?
If so, should we backport to 1.0.1 even though this will probably affect binary compatibility?
Adding a hacky org.apache.pekko scoped util class to Tapir should allow a workaround that can create Content-Length/Content-Type instances.
wdyt? @jrudolph @mdedetrich
The text was updated successfully, but these errors were encountered: