Lift

Subscribe to this topic:

• Entry #1: SBT or Maven?

  Wed, 13 Jun 2012:

  I've been meaning to post this for a bit, but a very strange bug caused by a third party service provided by my web host had my page rendered uneditable for a brief while. I wouldn't mind hosting this site on my own servers, but I've already paid for this place... Anyways, back to the post:

  At first, when I first started studying scala and lift, I was under the impression that Maven was the way to go to manage ones Lift (liftweb) projects. I began with (and still am) reading Programming in Scala (http://www.artima.com/shop/programming_in_scala) to learn the fascinating scala language.

  After reading enough to get an idea, I am ready to dive in and get some hands on experience with it.

  Really wanting to get my lift skills going, I figured I'd start with a mainly theoretical knowledge of scala, while hoping to exercise my scala skills while using lift.

  Perhaps I will will work on some scala desktop tools and applications as well as some scala/lift applications so I can learn from 2 angles simultaneously.

  I set up maven, followed some tutorials with it, then went to download lift. Hmm.. Lift was using SBT (Simple Build Tool) now? ok, now I'll have to play with them a bit and decide.

  Maven appeared to be the more robust and enterprise-ish ready, but SBT was what it promised to be, simple. The commands to start and manage a new project in SBT, to me, seemed much simpler that Mavens Architypes which needed to be defined. I can't image memorising the syntax of them all that need to be defined for a lift project. It seemed to me that everyone who used Maven just copied and pasted the same long line into the command line to get things started. Given the time, I try to avoid these situations of doing complex things 'just because' and without knowing the configurations.

  So, SBT was my choice in the end.

  However, SBT is evolving quickly, even doing a major update from 0.7 to 0.10 which broke a lot of the documentation since they were not backwards compatible. Many of the sample lift projects and templates are a bit confusing because its hard to tell which version of sbt, lift, and scala they used. I worked out the kinks, and finally have my environment the way I want it:
      - vim as my IDE
      - SBT to manage projects and dependencies
      - SBT container (called container now, instead of jetty. I believe it's still jetty 8) running a non-default port (SBT 0.7 and 0.10 have different ways of setting the default port).

  Unfortunately, I didn't log things as I was figuring them out.. so, I'll try track down which configurations I made and versions I used to put together some sort of tutorial/log

  
  

• Entry #2: Configuring SBT for Lift

  Thu, 14 Jun 2012:

  First, your going to need to install sbt. you can use your package manager like "apt-get install sbt", but last time it gave me the older version. I followed the unix instructions:

  Download sbt-launch.jar and place it in ~/bin.

  Create a script to run the jar, by placing this in a file called sbt in your ~/bin directory:

  java -Xms512M -Xmx1536M -Xss1M -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=384M -jar `dirname $0`/sbt-launch.jar "$@"
  

  Make the script executable:

  $ chmod u+x ~/bin/sbt
  

  Then, going through the process of figuring out sbt for the second time, I realized its actually quite easy if you follow the instructions they have on assembla. The first time was confusing because they give instructions for the outdated version (which has a higher version number [0.7 > 0.10] when .10 is actually newer)

  Lift documentation seems to be trying to catch up to the switch from sbt 0.7 to 0.10 (i still dont get why .1 is new than .7 since .7 is clearly greater than .1, is it normal to have .10 meaning "point ten"?) but the the using sbt section of assembla provided a good starting point.

  
  Basically, create a folder for a project with a build.sbt in the root, then a projectName/project/plugins.sbt containing the following which is now being suggested by the documentation:

  build.sbt

  name := "projname"
   
  scalaVersion := "2.9.1"
   
  seq(webSettings: _*)
  
  // If using JRebel with 0.1.0 of the sbt web plugin
  //jettyScanDirs := Nil
  // using 0.2.4+ of the sbt web plugin
  scanDirectories in Compile := Nil
  
  //resolvers += "Java.net Maven2 Repository" at "http://download.java.net/maven/2/"
  
  // you can also add multiple repositories at the same time
  resolvers ++= Seq(
    "Scala Tools Releases" at "http://scala-tools.org/repo-releases/",
    "Java.net Maven2 Repository" at "http://download.java.net/maven/2/"
  )
  
  // if you have issues pulling dependencies from the scala-tools repositories (checksums don't match), you can disable checksums
  //checksums := Nil
  
  libraryDependencies ++= {
    val liftVersion = "2.4" // Put the current/latest lift version here
    Seq(
      "net.liftweb" %% "lift-webkit" % liftVersion % "compile->default",
      "net.liftweb" %% "lift-mapper" % liftVersion % "compile->default",
      "net.liftweb" %% "lift-wizard" % liftVersion % "compile->default")
  }
  
  // when using the sbt web app plugin 0.2.4+, use "container" instead of "jetty" for the context
  // Customize any further dependencies as desired
  libraryDependencies ++= Seq(
    "org.eclipse.jetty" % "jetty-webapp" % "8.0.4.v20111024" % "container", // For Jetty 8
    //"org.eclipse.jetty" % "jetty-webapp" % "7.3.0.v20110203" % "container", // For Jetty 7
    //"org.mortbay.jetty" % "jetty" % "6.1.22" % "jetty,test", // For Jetty 6, add scope test to make jetty avl. for tests
    "org.scala-tools.testing" % "specs_2.9.0" % "1.6.8" % "test", // For specs.org tests
    "junit" % "junit" % "4.8" % "test->default", // For JUnit 4 testing
    "javax.servlet" % "servlet-api" % "2.5" % "provided->default",
    "com.h2database" % "h2" % "1.2.138", // In-process database, useful for development systems
    "ch.qos.logback" % "logback-classic" % "0.9.26" % "compile->default" // Logging
  )
  
  // by default, it listens on port 8080; use the following to override
  port in container.Configuration := 8081

  in the project/plugins.sbt put:

  libraryDependencies <+= sbtVersion(v => "com.github.siasia" %% "xsbt-web-plugin" % (v+"-0.2.10")) // moved to repo1
  // for the older version of the plugin, use the following instead:
  // you will need to change jetty's scope from 'container' to 'jetty' above
  //libraryDependencies <+= sbtVersion(v => "com.github.siasia" %% "xsbt-web-plugin" % ("0.1.0-"+v))
  

  then put your scala files in ../projectRoot/src/main/scala, and web template files in ../projectRoot/src/main/webapp

  
  I used this configuration to work through the chat tutorial on the liftweb.net

  Another option to quickly get your lift app going is to use lifty. this sbt plugin will create a lift app according to a certain recipe which you can use their sample or define your own. It worked quite well and I had their sample webapp runnign in no time.

  However, as a newcomer it didn't help me much because althoguh it put all the code in, I wasn't quite sure what it was doing. I think I prefer manualy setting up my lift project and will use lifty later on when I get a better clue. Hopefully learing to define my own recipes will be easy enough.

  Now to learn the fundamentals of lift...

  
  

• Entry #3: First Steps Developing with Lift

  Sat, 16 Jun 2012:

  Ok, so I'm going to let lifty build my project and directory structure... but, I'll make it start with the project-blank recipe.

  So far, I installed sbt 0.10 and put the suggested build.sbt and project/plugins.sbt into the project's root folder. But it turns out that lifty can take care of all that now anyways (they were out of sync before the 1.7.5-SNAPSHOT).

  But, it turns out that lifty was more convinient than I thought. I origionally used the 1.7.4 version, but it had issues with it and sbt .10, so the 1.7.5-SNAPSHOT version ended up working. Installing lifty is easy, as all you need to do is create the following global sbt settings:

  ~/.sbt/plugins/build.sbt

  resolvers += Resolver.url("sbt-plugin-snapshots", new URL("http://scalasbt.artifactoryonline.com/scalasbt/sbt-plugin-snapshots/"))(Resolver.ivyStylePatterns)

  addSbtPlugin("org.lifty" % "lifty" % "1.7.5-SNAPSHOT")

  (leave a one line space between both statements)

  ~/.sbt/build.sbt

  seq( Lifty.liftySettings : _*) 

  And that's it to installing Lifty! Now we jsut have to teach lifty the recipes~

  
  Since lifty will handle the .sbt files, we just need to create  a new folder to house a new Lift project, cd into that folder and run sbt.

  Once you reach the sbt console, teach your lifty plugin the default recipes with:

  lifty learn lift https://raw.github.com/Lifty/lifty/master/lifty-recipe/lifty.json

  and then you can create and run a blank lift project with:

  > lifty create lift project-blank > reload > container:start 

  or the sample project:

  > lifty create lift project > reload > container:start 

  
  to run the container (jetty) on a different port using sbt .10, you need to add this line to your build.sbt (be sure to leave a blank line between statements):

  port in container.Configuration := 8081
  

  Next, I found the exploring lift book to be quite clear. Starting out, and with a weaker scala background, I get lost sometimes when documentation dive right into the classes and packages that lift offers. This text uses Maven instead of sbt, but I was able to skip forward to learn the fundamentals of lift. The loose order in which I'll read this book:

  - Chapter 4: Templates in Lift
  - Chapter 7: Sitemap
  - Chapter 5: Snippets
  - Chapter 8: Mapper and Records
  - Chapter 6 : Forms
  
  Then i'll look into the advanced topics to get AJAX and COMET going

  
  

• Entry #4: Move to sbt 0.11.3 Broke Lifty

  Thu, 28 Jun 2012:

  I gave sbt 0.11.3 a go and lifty broke. I guess moving to the newest versions of sbt isn't the greatest idea, since it carries the potential for breaking its plugins. However, did I really need lifty anyways? Now I'm thinking not really.

  Thanks to heiflo on github who has a nice project going that has a skeleton project using lift 2.4, and sbt 0.11.2. This project contains all the configurations and such sorted out for the new versions of sbt. I just need to clone the project from https://github.com/heiflo/lift-basic-2.4-sbt-0.11.2, cd into the directory and run ./sbt

  The first load takes a while to download the dependancies, but then you are set. Now onto the coding...

  
  

• Entry #5: Github Fork For My Personalised Skeleton Liftweb App

  Fri, 29 Jun 2012:

  I forked heiflo's github project so that I can customize it a bit and use it as my skeleton liftweb projects in the future while not having to worry about it being updated and breaking my comfortable configurations. Mainly, I just wanted to change the jetty port...

  repo found here:

  https://github.com/neildaemond/lift-basic-2.4-sbt-0.11.2.git

  Feel free to clone/fork as you please