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.
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
On Nov 18, 2012 12:24 PM, "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?
> 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.
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?
> 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
> On Nov 18, 2012 12:24 PM, "Nolan Darilek" <no...@thewordnerd.info > <mailto: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?
> 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.
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.
> 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.
> 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.
> On 11/18/2012 06:24 PM, Nolan Darilek 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?
>> 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.
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).
