Module conventions for automated build system

[Nolan Darilek]

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?

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.

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.

Thanks.

[Diego Medina]

I use the shiro module on my lift apps regardless of the lift version, in other words, we don;t need shiro modules to be build for specific versions fo lift, I have personall yused shiro-lift with lift 2.5-SNAPSHOT as well as 2.5-M1 through M3, all using the same dependency of:

"eu.getintheloop"      %% "lift-shiro"     % "0.0.5"

Hope that helps.

  Diego

Diego
Sent from my android cell

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

[Nolan Darilek]

Interesting, I ran into some issues where SBT packaged both Lift 2.4 and 2.5 in one of my wars. It worked fine locally, but failed when deployed, and I saw both 2.4 and 2.5-SNAPSHOT paths in the exception classpath. I didn't spend lots of time debugging SBT, but I did note that when I updated the Shiro dependency to 2.5-SNAPSHOT, the exceptions went away.

So maybe a more appropriate question is, why does FoBo require the Lift version be included in its dependency, but Shiro doesn't?

[Peter Petersson]

Hi Nolan

Take a look at the lift-jquery-module [1] it's a less verbose module and
up to date in the module release process (FoBo is still only published
manually as snapshot's).

Here [2] is more about the release process.

The version schema is the lift version followed by the module version
and currently (for lift 2.5) the scala versions are 2.9.1, 2.9.1-1 and
2.9.2.
Yes, FoBo and the lift-jquery-module is making liftVersion a setting and
its a module build system convention.

[1] https://github.com/karma4u101/lift-jquery-module
[2] https://www.assembla.com/spaces/liftweb/wiki/Releasing_the_modules

best regards
Peter Petersson

[Peter Petersson]

On 11/18/2012 08:45 PM, Peter Petersson wrote:
> Hi Nolan
>
> Take a look at the lift-jquery-module [1] it's a less verbose module
> and up to date in the module release process (FoBo is still only
> published manually as snapshot's).
>
> Here [2] is more about the release process.
>
> The version schema is the lift version followed by the module version
> and currently (for lift 2.5) the scala versions are 2.9.1, 2.9.1-1 and
> 2.9.2.
> Yes, FoBo and the lift-jquery-module is making liftVersion a setting
> and its a module build system convention.

It makes it possible for the module's publishing scripts to automate the
non snapshot publishing.

[Richard Dallaway]

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 -SNAPSHOT).

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 https://github.com/liftmodules/buildhub)

 

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 if 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 publish script:

https://github.com/eltimn/lift-mongoauth/commit/49954cafd732dda38b9addd4c8a3e800666bf19a

Cheers

Richard