To answer part of your question...
On 18 November 2012 17:24, Nolan Darilek <no...@thewordnerd.info> wrote:
> Is there any information available on conventions for submitting a module
> to the automated build system? Specifically, are any provisions available
> for building a given module against multiple Lift versions, then correctly
> pulling in the right version at compile time?
First, I must say you're free to build a module however you want, and
publish wherever you want. However, you asked about the conventions. The
ones we have cover two scenarios:
1. "I want a build of a module now"
That's just a regular build and publish. There's nothing really special
about that, and each module has a Jenkins build over at
https://liftmodules.ci.cloudbees.com and all of them +publish so that if
you push to master, that'll be published (only works for SNAPSHOT builds as
production builds need GPG keys). That's the fully automatic build. It
builds against the version of Lift specified in your build.sbt
2. "Make sure the module is built against a new Lift release (or milestone)"
That's really what the liftVersion convention is for. We have a publish
script (https://github.com/liftmodules/publish) that asks what version of
Lift you're building against, pulls the module, modifies the liftVersion
and then tries to build and publish it. It not fully automatic: it's
scripted. That build is against a manually specified lift version, that
might be different from the version in the module's build.sbt (in fact, it
almost always will be, because the module's build version is usually a
Ok, there is theoretically a third scenario:
3. "Lift has changed, build my module"
We've not put this one into place yet, but the idea is that when Lift
builds, if that build succeeds, trigger a build of all the modules for
SNAPSHOT. But I've not put that in place yet (it's at
> I'm working on a pull request for the Lift Shiro module and am hoping to
> make it ready for automated builds, as its biggest current issue seems to
> be unavailability of the module for non-milestone Lift releases. But I
> don't know whether the module build system pushes out modules for multiple
> Lift versions, how often it does so, etc. Nor do I know how one goes about
> externalizing the Lift version against which to build the module.
So, to answer you question: there's not a automated way to build against
multiple version of Lift. We just build forward, onward and upward with
the latest versions.
I think Peter and Diego have given you all the pointers on externalising
against Lift versions.
For the moment I've used the solution from FoBo of making liftVersion a
> setting, pulling that version in as a dependency, and tacking it on after
> the Scala version so you might have lift-shiro_2.9.2_2.5-SNAPSHOT as a
> module name. Is this canonical, or just a FoBo convention?
> Feel free to point me to any current docs. I googled and found mention of
> the net.liftmodules organization but no best practices for how to publish a
> module. I guess ultimately I'll ask Tim to request that his module be
> included in the Jenkins instance, but I'd like to iron out the build system
> issues so it's just pull-and-go.
Yup, that's fairly easy to set up. Let us know when you're ready and we'll
set up a the Jenkins job. (There's also https://buildhive.cloudbees.com
you wanted your own build... not tried it myself, but sounds good).
BTW, here's the change to Tim's wonderful Mongo module to include it in the