Consider releasing a Jakarta-based flavour of Scalatra 3.x about scalatra HOT 11 CLOSED

Twirl 1.6.0 released: https://github.com/playframework/twirl/releases/tag/1.6.0

from scalatra.

Does #1573 make sense? I would release RC1 with it and then release GA after a while.

from scalatra.

Maintaining many variations of codebase is hard with the current our engineering resource, but we know there are needs both Servlet 4.0 and Jakarta because many existing Java softwares haven't been migrated to Jakarta.

My current plan is shifting Scalatra 2 to the maintenance mode and providing both Servlet 4.0 and Jakarta versions of Scalatra 3 in the future.

As you know, Scalatra 3 is mostly compatible with Scalatra 2 though some features which are not easy to keep maintained are dropped. So I think you can migrate your application to Scalatra 3 easily if you don't need Scalate/Atmosphere support.

Does providing Jakarta version of Scalatra 3 work for you?

from scalatra.

Yes, a Jakarta flavored Scalatra 3 would be perfect for me.

from scalatra.

Created a branch: #1533 based on 3.0.0-M4. I'm considering to release this branch as 3.0.0-M4-jakarta.

from scalatra.

Sounds great!

from scalatra.

3.0.0-M4-jakarta has been published to Maven central.

from scalatra.

from scalatra.

• #1536

from scalatra.

Scalatra 3 is going to be released with both support for javax and jakarta packages, so I can close this issue.

from scalatra.

I had just closed the issue yesterday, that something came to my mind.
Is the choice of putting either javax or jakarta in the artifact's version a good idea?
Which well eventually become 3.0.0-javax and 3.0.0-jakarta.

I'm afraid that this is not in line with SemVer: see https://semver.org/#spec-item-9 in particular for the paragraph regarding what would be considered a "pre-release" version with this naming scheme.

One of the issues with not conforming to SemVer, is that it will break tools like Dependabot or Renovate Bot, which — should they support pre-releases — will probably consider 3.0.0-javax as having a higher version that 3.0.0-jakarta.

To put things in perspective, other libraries chose for putting the jakarta qualifier in the artifact's ID.
As in:

• io.prometheus:simpleclient_servlet_jakarta
• io.swagger.core.v3:swagger-core-jakarta
• io.sentry:sentry-spring-boot-starter-jakarta

A new release of Twirl is imminent, so things will be soon ready for a Scalatra 3 release.
Let's make a future proof choice for this javax / jakarta naming scheme.

@xuwei-k: do you think it would possible to do like you did in #1536, but using the artifact ID?

from scalatra.