Are you looking for maintainers? I would like to help port Lift on Scala 3

[Lorenzo Gabriele]

Hello everybody,
I'm not a Lift user but I appreciate the framework and I'm a bit sad seeing it not being updated to Scala 3. I hope one day every application in the world can migrate to Scala 3 so we can delete Scala 2 and move on :)
I'm a Scala contributor and one of the maintainers of com-lihaoyi (the organization behind Mill, uPickle, Scalatags, fastparse, os-lib, etc.) so I have already experience maintaining open-source repositories. My Github account is: https://github.com/lolgab
My goal would be to help review and merge PRs like https://github.com/lift/framework/pull/1994 so we can get closer to supporting Scala 3.

Thank you,
Lorenzo

[Andreas Joseph Krogh]

Hi, I would absolutely love to see  Lift ported to Scala3, but lack the resources, unfortunately…

I might be willing to fund such effort though…

 

--

Andreas Joseph Krogh

CTO / Partner - Visena AS

Mobile: +47 909 56 963

and...@visena.com

www.visena.com

 

[David Pollak]

I'm +1

It might also be fun to roll the JSON macros I did into a Lift 4 (see https://github.com/what-cheer/netop/blob/main/macro/src/main/scala/whatcheer/macros/Jsonify.scala ) into Lift 4.

Also, web sockets instead of long polling.

Other requests?

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/liftweb/VisenaEmail.29.9590e7a41ade18bb.18b42fa976b%40origo-test01.app.internal.visena.net.

--

Fediverse: https://mastodon.social/@dpp

Lift, the simply functional web framework https://liftweb.net

Blog: https://blog.goodstuff.im

[Andreas Joseph Krogh]

På onsdag 18. oktober 2023 kl. 22:55:04, skrev David Pollak <feeder.of...@gmail.com>:

I'm +1

 

It might also be fun to roll the JSON macros I did into a Lift 4 (see https://github.com/what-cheer/netop/blob/main/macro/src/main/scala/whatcheer/macros/Jsonify.scala ) into Lift 4.

 

Also, web sockets instead of long polling.

 

Other requests?

I have a list of “small changes” we've done to Lift to make it better fit our needs. It's mainly configuration-stuff which lets you specify where “/lift” is (as a function), more configurable CometActors (wrt. initialization), bump to scala-xml:2.1.0 (and necessary changes to Html5Parser.parse).

 

I have no knowledge about React/Angular but hear about them all the time, so better interop with them would be great.

 

So, Mr. Bear-feeder; Any concrete plans on how to proceed with Lift 4 with Scala 3?

[Vitaliy L]

Another thing I see here is the end of community support for Jetty 9.x. All the newer versions of Jetty use Servlet versions higher than 3.1. It would be nice to bring support for the newer Jetty versions. 

[Andreas Joseph Krogh]

På torsdag 19. oktober 2023 kl. 11:48:17, skrev Vitaliy L <lvit...@gmail.com>:

Another thing I see here is the end of community support for Jetty 9.x. All the newer versions of Jetty use Servlet versions higher than 3.1. It would be nice to bring support for the newer Jetty versions. 

Yea, and change all references from javax => jakarta

[David Pollak]

Folks,

I've started creating GitHub issues with the Lift 4 tag: https://github.com/lift/framework/labels/Lift4

What I propose is we discuss Lift 4 features on this list and the person advocating for the feature distills the description into #Lift4 tickets on GitHub.

Once we see how big the list is, we get a sense of the amount of work and with that we figure out a rough timeline for getting Lift 4 out.

Sound reasonable?

Thanks!

David

PS -- @Lorenzo -- please start doing whatever code reviews and pull requests you want for the Scala 3 compatibility. No reason to not kick that stuff off quickly.

[Andreas Joseph Krogh]

På torsdag 19. oktober 2023 kl. 14:23:29, skrev David Pollak <feeder.of...@gmail.com>:

Folks,

 

I've started creating GitHub issues with the Lift 4 tag: https://github.com/lift/framework/labels/Lift4

 

What I propose is we discuss Lift 4 features on this list and the person advocating for the feature distills the description into #Lift4 tickets on GitHub.

 

Once we see how big the list is, we get a sense of the amount of work and with that we figure out a rough timeline for getting Lift 4 out.

 

Sound reasonable?

 

Thanks!

Excellent!

[Carlos Saltos]

If created a fork at https://github.com/talenteca/olon-web-framework

Olon version 1.0.0 is published for a while with a compatibility with Lift 3

And now I've just released Olon version 2.0.0 with a couple of improvements like:

* New versions for some dependencies like Scala XML and others.

* Clearing all the compiler warnings

* Adding API URL base links and fixing all scaladoc warnings

* Removing some deprecated parts and projects.

* Opening the door to start the Scala 3 upgrade path.

IMPORTANT: This is NOT a replacement for future Lift versions, is only a fork to fulfill my own company requirements with new dependencies at Talenteca.com until Lift 4 and newer versions are fully available.

Best regards,

Carlos Saltos

[David Pollak]

Ooohhh... super cool!

What's your ideal scenario for collaboration? The options I see are:

* merging your changes into the current Lift codebase and keeping the two codebases/JARs are separate things

* merging your changes into the current Lift codebase and having that be the single way forward (I understand that this seems like a domination move on my part to suggest it... I mean no offense, just want to enumerate the options)

* Having us take a look at the Olon changes and manually make them in Lift and keep the codebases/JARs are separate and diverging thing

* other options I'm not seeing

Looking forward to finding an optimal way to collaborate.

Thanks!

--

You received this message because you are subscribed to the Google Groups "Lift" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/liftweb/9aedbadc-3e93-4915-91d1-722f9a628ee9n%40googlegroups.com.

[Carlos Saltos]

Thank you for your message.

I see more reasonable the second option where we may merge only the critical commits into a single official Lift repo ... for the rest of non-critical changes, we can just use the third option.

With Olon 1.0.0 that's actually what happened, a critical security patch was merged and officially released on Lift 3.5.0.

In the other hand, Olon is also making a lot of drastic "crazy" non-critical changes like removing old deprecated methods, restructuring SBT projects, reconfiguring scaladocs and even considering removing old parts like the persistence and the json implementation (native Scala drivers and projects like json4s via Jackson are a lot better and faster nowadays) ... all these non-critical changes are rather too polemic to just include them into the official Lift releases and at the end not actually required for normal Lift users ... for the Olon "crazy" changes I would recommend the third option where we may take a look at Olon and manually apply the changes that make sense into Lift to make them official if they are actually bringing value to the official project and users.

I will try to open a couple of PRs with the critical part of the recent new Olon versions once all the tests are stable and specially when we check and double check our production servers are performing OK with the new changes and upgrades.

Best regards,

Carlos Saltos

[Woyce Bakins]

Hey Carlos,

can your branch be used with scala 3 already or is it a work in progress?

I would love to use liftweb but since scala 2 has been sunset, I was wondering about the state of scala 3 support in Liftweb.

Thanks.

[Lorenzo Gabriele]

Scala 2 has not been sunset. It's under active maintenance and there are no plans to sunset it.
You can safely use Scala 2 for the foreseeable future.

To view this discussion on the web visit https://groups.google.com/d/msgid/liftweb/552d7118-21e0-4b33-9120-0ea10642112cn%40googlegroups.com.

[Woyce Bakins]

Oh, thanks for the correction. Glad to know I can safely use liftweb without worrying about it.

[François Armand]

Hello,

We at rudder.io are trying to migrate to scala 3 and the dependencies to scala libs seems to be the hardest part (scala XML, scala combinatory parser), because they are the one that happened to be used on other libs both ported or not to scala 3, and so conflict at runtime. We likely will be able to workaround these problems, but it remainded that thread and so came take a look.

So I was wondering if the port of Lift to scala 3 was still on going, or if things have stalled.

Cheers !

[ari gold]

Hi there,

I work at a company where actually quite a few Lift maintainers used to work and, simply put, we're under the assumption that Lift development is not just stalled but over.

I'd suggest migrating away from Lift, before some unmet dependency breaks things for good 😅.

Would love to be wrong but #safetyfirst.

Cheers,

Ari

[David Pollak]

François,

I'd be interested in updating Lift to run under Scala 3.

I did some initial attempts, but my sbt skillz are, well, weak.

I think we'd have to figure out how to cross-compile between Scala 2.13 and 3 within SBT.

Once the cross-compilation works, we can start working through the dependencies.

Do you have good sbt skills? If so, can you create a development branch that does the 2.13/3 cross compilation? I'll slog through updating dependencies once I have something to work against.

Thanks,

David

PS -- Why Lift when it's mostly stagnated for the last 5+ years? I've done a bunch of looking around at Kotlin, Scala, Clojure, and Rust web frameworks.

I am particularly productive with the Clojure frameworks... they're very nicely done. But so much of the security stuff is roll-your-own at each endpoint.

The balance of the frameworks are both very heavy-weight in terms of the development cycle (Clojure and the REPL are awesome for productivity) and force the developer to think through the security implications of everything.

I haven't done Lift in anger for 9ish years... but coming back to it, I really, really appreciate all the things we collectively got right.

To view this discussion on the web visit https://groups.google.com/d/msgid/liftweb/19b22ea2-fcda-4261-adc9-c8cd8e869159n%40googlegroups.com.

[Andreas Joseph Krogh]

På fredag 05. juli 2024 kl. 23:01:25, skrev David Pollak <feeder.of...@gmail.com>:

François,

 

I'd be interested in updating Lift to run under Scala 3.

 

I did some initial attempts, but my sbt skillz are, well, weak.

 

I think we'd have to figure out how to cross-compile between Scala 2.13 and 3 within SBT.

 

Once the cross-compilation works, we can start working through the dependencies.

 

Do you have good sbt skills? If so, can you create a development branch that does the 2.13/3 cross compilation? I'll slog through updating dependencies once I have something to work against.

 

Thanks,

 

David

 

PS -- Why Lift when it's mostly stagnated for the last 5+ years? I've done a bunch of looking around at Kotlin, Scala, Clojure, and Rust web frameworks. 
 

 

I am particularly productive with the Clojure frameworks... they're very nicely done. But so much of the security stuff is roll-your-own at each endpoint.

 

The balance of the frameworks are both very heavy-weight in terms of the development cycle (Clojure and the REPL are awesome for productivity) and force the developer to think through the security implications of everything.

 

I haven't done Lift in anger for 9ish years... but coming back to it, I really, really appreciate all the things we collectively got right.

 

Just some thoughts:

Replacing javax.* => jakarta.* is necessary as well.

Do we really need to support scala < 3? I would be fine skipping scala-2 support all together.

 

We might be able to fund some effort porting to Scala-3.

[David Pollak]

I'm okay with Scala 3 only... but let's hear from others.

[Matt Farmer]

I’d concur with that. Cut a major version number and drop 2.x

For my part life has proven resilient to me getting involved in Lift stuff again. I’m not actively using it and I’ve largely ducked out of the Scala ecosystem as a whole because of some toxicity in the larger community. I’m just not around it as often as I used to be. 

I still *love* the core concepts Lift proved out and have tried to use them elsewhere where I can. But contributing back to Lift proper has been hard to get up to speed after having my kids and recent career changes. I keep thinking I’ll get back to it and have been wrong so far. Maybe 2024 will be the year. 

On Jul 6, 2024, at 8:47 AM, David Pollak <feeder.of...@gmail.com> wrote:



<noname>

 

--

Fediverse: https://mastodon.social/@dpp

Lift, the simply functional web framework https://liftweb.net

Blog: https://blog.goodstuff.im

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/liftweb/CAH6e9Lgfkd%2BL5r%2BWwoxvFEAL1D4JDYx4eZpDg6AndEzASOhRoA%40mail.gmail.com.

[Andreas Joseph Krogh]

Looking into the crystal ball: It'd be great if we'd be able to lay out some long term plan for Lift, supporting modern stateless frameworks etc.

We've invested heavily in Scala/Lift in our application(s), but we we have to bow to the modern “way of doing things”, using more client side frameworks (Angular/React) and stateless/OpenAPI stuff. It'd be great to be able to integrate more with these modern frameworks.

 

--

Andreas Joseph Krogh

CTO / Partner - Visena AS

Mobile: +47 909 56 963

and...@visena.com

www.visena.com

To view this discussion on the web visit https://groups.google.com/d/msgid/liftweb/6AC91CCA-8005-4719-B249-A898F49845A9%40frmr.me.
 

 

 

[David Pollak]

Andreas,

Cool!

Let's start another thread (can you create it) to gather requirements for Lift 4?

I'm thinking it includes:

* Scala 3 only

* Generation of OpenAPI schemas from API endpoints (in keeping with how Schemafier is the source of truth for DB schemas) but also support for ingesting OpenAPI docs (both of these things should be doable with macros)

* Support for JWTs

* Support for middleware at both the API and stateful HTML side (maybe even doing HTML middleware via SiteMap)

* Moving Lift's Comet support to Web Sockets and also client-side Ajax can work through the Web Socket if one is open

A bunch of the above becomes a lot easier with Scala 3's macros. I've seen how macros are used in Rust-land and there are a ton of possibilities!

Would love to get other requirements from other folks.

Thanks,

David

To view this discussion on the web visit https://groups.google.com/d/msgid/liftweb/VisenaEmail.d.aec91eb788b8bd0.190a7fe2cdb%40origo-test01.app.internal.visena.net.

[Matt Farmer]

We could try out GitHub projects for collecting and discussing these ideas. I know we’ve historically heavily biased toward the ML, but…. Well I don’t know about anyone else but I feel like my inbox is more of a disaster than ever. I have a hard time keeping up. Heh. 

If folks are supportive I’m happy to do a bit of setup on the lift org. 

On Jul 13, 2024, at 7:57 AM, David Pollak <feeder.of...@gmail.com> wrote:



Andreas,

Cool!

Let's start another thread (can you create it) to gather requirements for Lift 4?

I'm thinking it includes:

* Scala 3 only

* Generation of OpenAPI schemas from API endpoints (in keeping with how Schemafier is the source of truth for DB schemas) but also support for ingesting OpenAPI docs (both of these things should be doable with macros)

* Support for JWTs

* Support for middleware at both the API and stateful HTML side (maybe even doing HTML middleware via SiteMap)

* Moving Lift's Comet support to Web Sockets and also client-side Ajax can work through the Web Socket if one is open

A bunch of the above becomes a lot easier with Scala 3's macros. I've seen how macros are used in Rust-land and there are a ton of possibilities!

Would love to get other requirements from other folks.

Thanks,

David

On Fri, Jul 12, 2024 at 1:33 PM Andreas Joseph Krogh <and...@visena.com> wrote:

Looking into the crystal ball: It'd be great if we'd be able to lay out some long term plan for Lift, supporting modern stateless frameworks etc.

We've invested heavily in Scala/Lift in our application(s), but we we have to bow to the modern “way of doing things”, using more client side frameworks (Angular/React) and stateless/OpenAPI stuff. It'd be great to be able to integrate more with these modern frameworks.

 

--

Andreas Joseph Krogh

CTO / Partner - Visena AS

Mobile: +47 909 56 963

and...@visena.com

www.visena.com

<noname>

To view this discussion on the web visit https://groups.google.com/d/msgid/liftweb/CAH6e9Lgo9yzgQXhUdGaN8LnG5P0kLtN2vbtubCjnxsHfrhdOpA%40mail.gmail.com.

[David Pollak]

👍🏽🙏🏽

Fediverse: https://mastodon.social/@dpp

Lift, the simply functional web framework https://liftweb.net

Blog: https://blog.goodstuff.im

To view this discussion on the web visit https://groups.google.com/d/msgid/liftweb/D9CF6093-E1BD-4270-BDF0-A662E5B9BCDA%40frmr.me.

[Matt Farmer]

I’ve created https://github.com/orgs/lift/projects/5/views/1

Anyone in the organization can add items here. If anyone else on this thread wants access to add items, lmk. These are all issues in framework under the hood so we can have discussion on each one in turn if needed. I’ve imported a bunch of the pre-existing issues that we’d flagged for Lift 4 as a starting point and added a few from David’s most recent email.

This should at least serve as a good starting point for coordinating. :) 

To view this discussion on the web visit https://groups.google.com/d/msgid/liftweb/CAH6e9LgyVbSa%3DtXGADLOXt_mBcNasQ3_tk6shF9Pj5Ryo%3DZcmg%40mail.gmail.com.