2.10 release?

[stephanos]

Hey guys,

I was wondering if a 2.10 release is in the making since the RC is out?

I'm mainly asking because Lift is a dependency to the Rogue library which is stuck at 2.9 now ...

Regards

Stephan

[David Pollak]

On Mon, Nov 5, 2012 at 7:51 AM, stephanos <stephan...@gmail.com> wrote:

Hey guys,

I was wondering if a 2.10 release is in the making since the RC is out?

We are working against Scala 2.10 on the lift_30 branch. The branch will not build because the ScalaZ dependency is not yet published against Scala 2.10-RC1 (okay, it's 2012 and Scala is still more version fragile than C++... this should be fixed by now and is just a royal pain for any organization that has a complex Scala app... but I've ranted about this in the past: http://blog.goodstuff.im/scala-s-version-fragility-make-the-enterprise-argument-near-impossible )

 

Once this issue is resolved, there'll be a snapshot of Lift 3.0 published against Scala 2.10-xxxx

I'm mainly asking because Lift is a dependency to the Rogue library which is stuck at 2.9 now ...

Regards

Stephan

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code
 
 
 

--

Telegram, Simply Beautiful CMS https://telegr.am

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

Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im

[stephanos]

Thanks for the reply!

So I'll be going to the next community then and ask them :-)

Stephan

[Naftoli Gugenheim]

The only dependency in lift on scalaz is in lift-json.

In any case, I highly doubt Rogue wants to depend on Lift 3.0 at this point.

[Naftoli Gugenheim]

However there should a 2.5-SNAPSHOT in the near future. Locally I have:

~/dev/liftweb/framework (nafg_wip_scala210 ✘)✭ ᐅ ls **/target/scala-2.10.0-RC1/*-SNAPSHOT.jar

core/actor/target/scala-2.10.0-RC1/lift-actor_2.10.0-RC1-2.5-SNAPSHOT.jar

core/common/target/scala-2.10.0-RC1/lift-common_2.10.0-RC1-2.5-SNAPSHOT.jar

core/json-ext/target/scala-2.10.0-RC1/lift-json-ext_2.10.0-RC1-2.5-SNAPSHOT.jar

core/json/target/scala-2.10.0-RC1/lift-json_2.10.0-RC1-2.5-SNAPSHOT.jar

core/util/target/scala-2.10.0-RC1/lift-util_2.10.0-RC1-2.5-SNAPSHOT.jar

persistence/db/target/scala-2.10.0-RC1/lift-db_2.10.0-RC1-2.5-SNAPSHOT.jar

persistence/ldap/target/scala-2.10.0-RC1/lift-ldap_2.10.0-RC1-2.5-SNAPSHOT.jar

persistence/mapper/target/scala-2.10.0-RC1/lift-mapper_2.10.0-RC1-2.5-SNAPSHOT.jar

persistence/mongodb-record/target/scala-2.10.0-RC1/lift-mongodb-record_2.10.0-RC1-2.5-SNAPSHOT.jar

persistence/mongodb/target/scala-2.10.0-RC1/lift-mongodb_2.10.0-RC1-2.5-SNAPSHOT.jar

persistence/proto/target/scala-2.10.0-RC1/lift-proto_2.10.0-RC1-2.5-SNAPSHOT.jar

persistence/record/target/scala-2.10.0-RC1/lift-record_2.10.0-RC1-2.5-SNAPSHOT.jar

web/testkit/target/scala-2.10.0-RC1/lift-testkit_2.10.0-RC1-2.5-SNAPSHOT.jar

web/webkit/target/scala-2.10.0-RC1/lift-webkit_2.10.0-RC1-2.5-SNAPSHOT.jar

web/wizard/target/scala-2.10.0-RC1/lift-wizard_2.10.0-RC1-2.5-SNAPSHOT.jar

Missing is:

[error] (lift-jpa/*:update) sbt.ResolveException: unresolved dependency: org.scala-libs#scalajpa_2.10.0-RC1;1.4: not found

[error] (lift-couchdb/*:update) sbt.ResolveException: unresolved dependency: net.databinder#dispatch-http_2.10.0-RC1;0.7.8: not found

[error] (lift-squeryl-record/*:update) sbt.ResolveException: unresolved dependency: org.squeryl#squeryl_2.10.0-RC1;0.9.5-1: not found

[error] (lift-json-scalaz/*:update) sbt.ResolveException: unresolved dependency: org.scalaz#scalaz-core_2.10.0-RC1;6.0.4: not found

Note that Derek has now published scalajpa to sonatype releases, so we only need to wait until it's synchronized to maven central.

Have I left any modules out?

[Diego Medina]

Hi Mario,

For now you;ll have to manually compile and publish-local this branch
https://github.com/lift/framework/tree/nafg_wip_scala210

Regards,

Diego


On Sun, Nov 11, 2012 at 9:01 PM, Mario Sangiorgio
<mariosa...@gmail.com> wrote:
> Hi,
>
> I am new to this mailing-list and I hope it is ok if I ask this question
> here.
>
> I am using lift-json in a project of mine, and I am experimenting with
> macros, so I need a version of the library compatible with Scala 2.10.
>
> I saw that in the latest message you mentioned some 2.5-SNAPSHOT releases.
> Are they available on a public repository?
>
> Mario

Diego Medina
Lift/Scala Developer
di...@fmpwizard.com
http://www.fmpwizard.com

[Mario Sangiorgio]

Thank you for your quick reply.

Mario

[stephanos]

Hi,

I was wondering, what's the status of Lift 2.5 for Scala 2.10 ?

Last time (3 weeks ago) there only seemed to be a few missing dependencies ...

Regards,

Stephan

[Naftoli Gugenheim]

What's missing now is the lift-couchdb has to be ported to the new databinder dispatch (http://dispatch.databinder.net/Dispatch.html). Feel free to take it on.

[Jeppe Nejsum Madsen]

stephanos <stephan...@gmail.com> writes:

> Hi,
>
> I was wondering, what's the status of Lift 2.5 for Scala 2.10 ?
> Last time (3 weeks ago) there only seemed to be a few missing dependencies

This is the latest status from Naftoli:

"The only thing holding back Lift 2.5 from Scala 2.10 is that
lift-couchdb is written against the old Databinder Dispatch "classic",
which is not built against 2.10. Someone needs to port it to the new
Dispatch "reboot." I was hoping to find time soon, but if someone can
take that on it would be wonderful. (They need not worry about 2.10,
only switch to the new API; see
http://dispatch.databinder.net/Dispatch.html.)"

/Jeppe

[stephanos]

I wanted to have a look at it but I'm quite confused about the build settings, never worked with crossbuilding before.

Where do I find the lift framework build setup for 2.10 ?

[Naftoli Gugenheim]

~/dev/liftweb/framework (nafg_wip_scala210 ✘)✹✭ ᐅ grep -n dispatch project/Dependencies.scala

40:  lazy val dispatch_http          = "net.databinder"             % "dispatch-http"      % "0.7.8"   cross CVMappingAll

So just change that, and the relevant source code in lift-couchdb.

To build use the included liftsh (or sbt 0.12+).

--

[stephanos]

I had a really close look at the source code. I must say I didn't use a lot of either dispatch classic or reboot. So take this with a grain of salt.

The concepts completely changed in dispatch 0.9 (reboot) so it's not only porting lift-couchdb to a new API but a completely new approach as far as I see it. It seems trivial at first because the project only imports 5 items from dispatch: Handler, Request, Http, :/ and StatusCode. What makes it difficult is that the first 2 don't exist anymore in that form or another. To get this functionality back without a re-design it seems the only option is to use low-level classes from the underlying ning library.

But I'll have a look at it again in the morning, maybe my first impression is wrong.

By the way, on the dispatch mailing list I was told that they plan to release a 2.10 version for dispatch classic when the final is out. So this might be plan B.

Cheers

Stephan

[Naftoli Gugenheim]

On Thu, Nov 29, 2012 at 4:06 PM, stephanos <stephan...@gmail.com> wrote:

By the way, on the dispatch mailing list I was told that they plan to release a 2.10 version for dispatch classic when the final is out. So this might be plan B.

Then it's up to you whether to bother. It would be great to port the legacy code, but we don't need to.

If you want to work on it, you can show the code snippets in question on the dispatch list and ask how to rewrite it. I can't imagine they won't support as many usages.

When you say "redesign," do you mean changing the lift-couchdb API, or just that it's more work?

Thanks.

[stephanos]

Well, as far as I can see the only API anyone should use are JSONRecord and CouchRecord - this would be doable without breaking the API (on first look). But since most of the other classes are also public I cannot be completely sure. For instance a lot of methods return an instance of dispatch's Handler - which does not exist anymore.

I'll have a look at it and see if it can be done in a sensible way.

If it doesn't work or I give up we would just have to wait for the dispatch classic 2.10 release.

Cheers

[Naftoli Gugenheim]

DPP can we break APIs that expose classic dispatch?

[Erik Post]

Hi Naftoli,

Is there any way to build Lift without the offending dependencies? I don't need Couchdb or, as far as I'm aware, Dispatch in my project.

Cheers,

Erik

[Diego Medina]

You would have to do some manual work, but something like this should work:

git clone git://github.com/lift/framework.git
cd framework
git checkout nafg_wip_scala210 //This is the branch Naftoli has been working on

You may need to delete your ivy folder, because there are times that
sbt will not do the right thing, and will give you the 2.5-SNAPSHOT
from maven central, instead of the local one

So,

rm -Rf ~/.ivy2

then,

./liftsh

prompt message> ++2.10.0-RC2 //This will change the current version of scala
Then, you will have to go one by one the different sub projects and
publish-local, something like:

> project lift-webkit
> publish-local
>project lift-json
> publish-local

sbt has autocoplete, so you can see which are all the subproject names.

Of course, you could go and use some bash scripting magic to make it
easier, but those are pretty much the steps you would need.

Hope that helps.

Diego

[Erik Post]

Hi Diego,

I'd tried building the whole thing, but I didn't think of building the modules individually. Thanks a lot for the tip and for the elaborate howto!

Cheers,

Erik

[Naftoli Gugenheim]

Yes sure, just publish-local in the root project. Sbt will publish-local whatever it can. In other words, anything that fails, or depends on something that fails, will not be installed to ~/.ivy2/local, and everything else will.

Of course you should probably test it first; if there are any modules that compile but fail tests then you don't want to publish them. In that case you can do something like lift-webkit/publish-local. That should run publish-local on webkit and everything it depends on.

In the past the Lift build had a setting to make publish or publish-local depend on test, not sure if there's a quick way to do that at the moment (you could always do the sbt config directly, maybe something like set publishLocal in ThisBuild <<= testQuick in ThisBuild).

On Sun, Dec 9, 2012 at 11:29 AM, Erik Post <eriks...@gmail.com> wrote:

[Richard Dallaway]

Maybe this raises the question of considering moving Couchdb out to a module?  Assuming that's possible and lower-effort than the dispatch port, maybe it allow the 2.10 build to proceed and we can figure out, as a community, how to progress the Couch changes.

Just a thought.  Feel free to shoot it down.  Obviously it's crazy idea if there's anyone relying on the Couch support.

Richard

[Jeppe Nejsum Madsen]

On Thu, Dec 13, 2012 at 11:16 AM, Richard Dallaway <ric...@dallaway.com> wrote:

Maybe this raises the question of considering moving Couchdb out to a module?  Assuming that's possible and lower-effort than the dispatch port, maybe it allow the 2.10 build to proceed and we can figure out, as a community, how to progress the Couch changes.

Just a thought.  Feel free to shoot it down.  Obviously it's crazy idea if there's anyone relying on the Couch support.

Good idea! I think moving as much non-essential code into modules as possible is worthwile (as for persistence, I think at least Mapper, Squeryl & probably mongo count as essential ;-)

Btw, I went looking for modules info on liftweb.net, but didn't find anything. Shouldn't we put some prominent page up there?

/Jeppe

[Naftoli Gugenheim]

+1

Any takers? ;)

(This would be done relative to master, then all the 2.10 branch would need is a little rebase, and it would hopefully be ready for code review and merge into master.)

[Peter Petersson]

That's a excellent idea, maybe a short introduction about modules containing a link to the wiki pages about building/contributing/creating and using modules https://www.assembla.com/spaces/liftweb/wiki/Modules followed by a list of existing modules with the module name a short explanation and a link to github. Ending the page with a encouragement to add more modules to Lift and extending the list.

best regards
  Peter Petersson

[Ali S. Rashid]

lift-couchdb split from framework and packages renamed to 'net.liftmodules.*'.  Should be ready to move to https://github.com/liftmodules (haven't tried using it but all tests passing).

Lift changes https://github.com/arashi01/framework/commit/270215b7054880a3315fabd821411c10d6a44c53

Cheers,

Ali

[Peter Petersson]

Awesome!
Cheers,
  Peter

[Diego Medina]

Could you send a pull request so we can include this in LIft 2.5-M4 ?

[Richard Dallaway]

On 14 Dec 2012, at 18:28, "Ali S. Rashid" <a.ra...@zantekk.com> wrote:

lift-couchdb split from framework and packages renamed to 'net.liftmodules.*'.  Should be ready to move to https://github.com/liftmodules (haven't tried using it but all tests passing).

fantastic - I'll fork the module over to liftmodules an see if I can try it out....

[Ali S. Rashid]

Done. https://github.com/lift/framework/pull/1383

[stephanos]

I was wondering, what's the status of the Scala 2.10 release of Lift?

On Tuesday, November 6, 2012 3:26:51 AM UTC+1, nafg wrote:

[Naftoli Gugenheim]

I almost have it cross-building with the same source. I hope we can release before the 7th, so we can be on the 2.10 release announcement (I think that's the date).

I have one issue that just showed up with lift-json, I hope to resolve it G-d willing.

[Naftoli Gugenheim]

Sorry my mistake. It was released already on the 4th. I hope the json-ext issue will be resolved ASAP so we can release for 2.10.

[Alexandre Richonnier]

Hi!

I did a pull request for couchdb module (at least all test run well) with scala 2.10.0 + "dispatch-http" % "0.8.9".

0.8.9 advantages are : build on scala 2.10 and api between 0.7.8 and reboot 0.9.

Feel free to test.

https://github.com/liftmodules/couchdb/pull/1