Lift is an open source project powered by Assembla
Assembla offers free public and private SVN/Git repositories and project hosting with bug/issue tracking and collaboration tools.
Viewing version 11 created almost 5 years ago by alexblack.
Starting with version 2.3-RC1 (currently SNAPSHOT), Lift Framework uses SBT for builds.
Components of Lift Project have been grouped into multiple repositories under Lift organization in Github.
- Repository: https://github.com/lift/framework
./liftsh +update +clean +publish
- Repository: https://github.com/lift/modules
./liftsh +update +clean +publish
- Repository: https://github.com/lift/examples
./liftsh +update +clean +deliver
- Repository: https://github.com/lift/superbuild
cd sbt && ./liftsh update clean publish
For convenience, there are helper scripts,
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.
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
- 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 docgenerates the aggregated apidocs for the full project in addition to apidocs for each artifacts.
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 "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
Choose two versions to compare, or click the link to view it.