Introduction

External modules are those created and managed outside of the Lift source code. They are distinct from the committer-managed modules that form part of Lift.

There’s no requirement that external modules be published or hosted at any particular location. However there is an experimental build system and module repository hosted by CloudBees. This page describes this particular hosted repository and build.

Other repositories include those use by:

• lift-shiro – Integration between Apache Shiro and the Lift Web framework.
• I’m sure there are others; please add them here.

Goals of the CloudBees repository

First, to have a repository non-committers can access, as a place for publishing modules as binary artifacts, ready to use in your Lift projects.

Second, as an experiment towards being able to automatically build modules as new versions of Lift become available. This aim is far from being fulfilled. The point of this is to reduce delays between new versions of Lift, and corresponding versions of modules. There may be better ways to achieve this, which is partly why this whole service is experimental.

Finally, as a convenient location for Lift users to locate third-party modules.

Using modules from the CloudBees repository

Including an external module in your Lift project means adding the repository dependency to your SBT build, then including the module or modules you want to use, and calling the `init` method on the module in your `Boot` class.

Modules in alphabetical order:

The latest list of external modules can been seen on the build server page. The best source of documentation for each module can be found on the module’s GitHub page.

Step 1: Adding the repository to SBT

For 0.10 and later:

  resolvers += "liftmodules repository" at "http://repository-liftmodules.forge.cloudbees.com/release/"

  lazy val liftModulesRelease = "liftmodules repository" at "http://repository-liftmodules.forge.cloudbees.com/release/"

Step 2: Including the module in your Lift project

The naming scheme for modules includes the Lift version you are using, typically defined by the SBT value “liftVersion”. Let’s say you want to include version 4.2 the liftmodule-foo with your current version of Lift. You’d add this line to your SBT dependencies:

  "net.liftmodules" %% "foo" % (liftVersion+"-4.2")

There may be some differences between modules: do check the README in the module’s github page for details.

Step 3: Initialize the module in Boot

At a minimum all modules should “do the right thing” with a default init method call:

  import net.liftmodules.foo
  Foo.init

But again, check the specific module’s GitHub page for options.

Contributing a module into the CloudBees repository

Current status is that we have a Jenkins build server, and we have a repository to publish into. Unfortunately, we have to manually publish to the repository. CloudBees are working on allow us to publish a build directly to the repository from Jenkins. The issue is that +publish doesn’t create the directory structure in the repository, meaning we have to create it by hand.

Here are the steps:

1. Have your module source hosted on a public Git repository (most people seem to use GitHub).
2. Ask on the mailing list for access to the CloudBees build interface (jono or richard will reply). It really helps us have trust if you’ve been on the mailing list for a while, posting and answering questions.
3. Once you have access, set up a Jenkins build for your project (clone one of the existing ones is not a bad place to start).
4. Publish. It’s up to you if you’re publishing to snapshot or release. Take a look at the SBT configuration for existing projects to see how to configure credentials for publishing.

Module owners are encouraged to request access to implicit.ly to publish release notes, probably using posterous-sbt, under the net.liftmodules tag.

Useful links:

• The CloudBees facility we’re using: CloudBees & Open Source
• The liftmodules snapshot and release repos: https://liftmodules.forge.cloudbees.com/
• How to mount the repositories. Useful for manually creating directories for publishing builds. http://wiki.cloudbees.com/bin/view/DEV/Mounting+DAV+Repositories
• The Jenkins instance: https://liftmodules.ci.cloudbees.com/

Still to do:

• Allowing an automatic publish from a Jenkins build
• Figure out how to use Jenkins builds to publish to snapshot or release
• Figure out a SBT/Jenkins configuration to allow a new version of Lift to trigger an appropriate build and publish for all modules. For Lift snapshots and new Lift versions/milestones.