Lift is using Jenkins to continuously build the SNAPSHOT version whenever code is committed on github. The status of the builds can be found on CloudBees
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.
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 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:
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
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.
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:
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
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
Publishing to local Maven repository
For publishing to the standard local Maven repository, $HOME/.m2/repository, issue these commands in the sbt-console:
set publishTo in ThisBuild := Some(Resolver.file("file", new File(Path.userHome.absolutePath+"/.m2/repository")))