Lift

Starting with version 2.3, Lift Framework uses SBT v0.7.7 for builds.
Starting with version 2.5, Lift Framework uses SBT v0.12.0 for builds.

Repositories

Components of Lift Project have been grouped into multiple repositories under Lift organization in Github.

• Lift Framework
  • Repository: https://github.com/lift/framework
  • Build: ./liftsh +update +clean +publish

• Lift Modules
  • Repository: https://github.com/lift/modules
  • Build: ./liftsh +update +clean +publish

• Lift Examples
  • Repository: https://github.com/lift/examples
  • Build: ./liftsh +update +clean +deliver

• Lift Superbuild
  • Repository: https://github.com/lift/superbuild
  • Build: cd sbt && ./liftsh update clean publish

Building

For convenience, there are helper scripts, liftsh and buildall. liftsh wraps SBT with sensible default tweaks for Lift. Every one of the four main Lift repos contains its own liftsh script (superbuild’s is under the sbt/ directory). You are free to override these settings either via LIFTSH_OPTS environment variable or by having them tucked inside ~/.liftsh.config. Check out the inlined variable DEFAULT_OPTS inside liftsh for the the default tweaks.

Build.properties

The + in the build command ./liftsh +update +clean +publish indicates all versions should be built, e.g. 2.9.1, 2.9.0-1, 2.8.2 etc. If you modify project/build.properties, you can configure the build to just build the version of that you need, e.g. build.scala.versions=2.9.1

liftsh

liftsh being a simple wrapper around SBT, all the usual SBT commands are available at your disposal. Specifically, Lift follows exactly the same set of actions for build workflow as recommended and documented by SBT.

A few interesting things about Lift’s SBT setup that you might want to be aware of:

• Download repositories:
  • ScalaToolsSnapshots is not available during release build but automatically enabled for SNAPSHOT build.
  • Maven local repository is configured (DownloadRepositories.local) but not available by default during build. To use it, set maven.local=true. Although this can be set as user property, setting it as system property is recommended like so:
    LIFTSH_OPTS="-Dmaven.local=true" ./liftsh update package
• Publishing:
  • publish action by default publishes artifacts to ~/.m2/repository. This helps other Maven based applications using Lift to benefit.
  • To publish to nexus.scala-tools.org, you need to set publish.remote=true. As usual, setting is as system property is recommended like so:
    LIFTSH_OPTS="-Dpublish.remote=true" ./liftsh update publish
  • By default the Nexus credentials from ~/.m2/settings.xml is used. You can override this by having the credentials specified in ~/.ivy2/.scalatools.credentials instead as described here
• API Docs (Scaladocs):
  • liftsh doc generates the aggregated apidocs for the full project in addition to apidocs for each artifacts.

buildall

The buildall script, located in the superbuild repo under the scripts/ directory, essentially does a full build of each of the repos in dependency order (superbuild, then framework, modules, and examples). Running buildall with no arguments does a full local clean and deployment (to your local .m2 and .ivy2 directories), and is intended to be an equivalent to the old Maven full build before the repos were split. Any command line arguments to buildall are prepended to each repo’s liftsh call. For example, if you wanted to build at warn level or higher:

superbuild/scripts/buildall warn

Note that the buildall script assumes that your local checkouts of the superbuild, framework, modules and examples repos are sibling directories.

Building for a Specific Sub-Project

Sometimes you want to only build one subproject of the top-level (e.g. framework, modules) project. You can do this by prepending a project qualifier to the liftsh command:

./liftsh "project lift-testkit" test

Troubleshooting

• In case of trouble, always do the following before trying again:
  ./liftsh clean-plugins reload clean-cache clean-lib update.

• SNAPSHOT builds (on master) rely upon lift-sbt plugin which in turn might change. Oftentimes, the project descriptor might use newer configuration from lift-sbt plugin while the project is stuck with an older incompatible plugin descriptor. In such cases, you can clean up the older plugin by doing the following. Newer plugin will be automatically downloaded next time:
  rm -Rf project/plugins/src_managed project/plugins/target