Liftweb without Maven?

[tk050305cnx]

I am new to Liftweb. Unfortunately, the example app in the "getting
started" doc did not work. That is... Maven did not produce the
expected output. I don't want to bother with Maven at this time. Can
you point me to a source that describes how to set up a helloworld
type of application manually and deploy it on Tomcat? Is there any
Eclipse automation for that?

Cheers, CNX

[João Pereira]

Hello,

I find that maven will ease your work a lot. Usually it take only one
step to get a lift app running.

mvn jetty:run

if you want to create an eclipse project for the downloaded app, you
just do mvn eclipse:eclipse and then import it to eclipse.

Not using maven you'll have to deal with all the dependency management
by yourself :(

Can you specify what do you expected from maven? what were the
problems encountered?

--
João Miguel Pereira, PMP
http://jpereira.eu
http://www.linkedin.com/in/joaomiguelpereira
joaomigue...@gmail.com
(351) 96 275 68 58

[marius d.]

Even if I find maven quite helpful for Lift there are people that just
want to stay away from maven. I can understand that. Perhaps it would
be helpful to also have some ant script to build a lift project? ...
or perhaps have a downloadable zip archive from lift's site that
contains incipient projects like the results produced by Lift's
archetypes? ... so that people can just download that project zip file
with the ant build in it and then start building the app on top of
that? ... would that work ?

Br's,
Marius

On Apr 14, 2:23 pm, João Pereira <joaomiguel.pere...@gmail.com> wrote:
> Hello,
>
> I find that maven will ease your work a lot. Usually it take only one
> step to get a lift app running.
>
> mvn jetty:run
>
> if you want to create an eclipse project for the downloaded app, you
> just do mvn eclipse:eclipse and then import it to eclipse.
>
> Not using maven you'll have to deal with all the dependency management
> by yourself :(
>
> Can you specify what do you expected from maven? what were the
> problems encountered?
>

> On Tue, Apr 14, 2009 at 12:11 PM, tk050305cnx <tk050305...@gmail.com> wrote:
>
> > I am new to Liftweb. Unfortunately, the example app in the "getting
> > started" doc did not work. That is... Maven did not produce the
> > expected output. I don't want to bother with Maven at this time. Can
> > you point me to a source that describes how to set up a helloworld
> > type of application manually and deploy it on Tomcat? Is there any
> > Eclipse automation for that?
>
> > Cheers, CNX
>
> --
> João Miguel Pereira, PMPhttp://jpereira.euhttp://www.linkedin.com/in/joaomiguelpereira

> joaomiguel.pere...@gmail.com

[Viktor Klang]

On Tue, Apr 14, 2009 at 1:38 PM, marius d. <marius...@gmail.com> wrote:

Even if I find maven quite helpful for Lift there are people that just
want to stay away from maven. I can understand that. Perhaps it would
be helpful to also have some ant script to build a lift project? ...
or perhaps have a downloadable zip archive from lift's site that
contains incipient projects like the results produced by Lift's
archetypes? ... so that people can just download that project zip file
with the ant build in it and then start building the app on top of
that? ... would that work ?

Nice angle!
Or perhaps have an online service where you can specify the archetype details and have a compressed payload downloaded?
 

--
Viktor Klang
Senior Systems Analyst

[tk050305cnx]

Thanks for your comments, João.

I am using Ant (or respectively the Eclipse built-in Ant-based
dependency management) for my Java and Scala work. I am on Vista.
Maven sputtered a number of different error messages on several
trials. I don't want to learn Maven and get to the bottom of this.
Busy schedules... What I am trying to do is to fit Lift into my
existing dev tool stack, Eclipse, Tomcat, MySQL, and (possibly)
Hibernate.

Cheers, CNX

[Timothy Perrett]

Didn't Eric make some ant scripts ages ago... I certainly remember someone
making them prior to this discussion.

Tim

[TylerWeir]

> expected output. I don't want to bother with Maven at this time. Can

You'll have a better experience if you take the time to learn how
maven works.

[marius d.]

On Apr 14, 2:40 pm, Viktor Klang <viktor.kl...@gmail.com> wrote:

> On Tue, Apr 14, 2009 at 1:38 PM, marius d. <marius.dan...@gmail.com> wrote:
>
> > Even if I find maven quite helpful for Lift there are people that just
> > want to stay away from maven. I can understand that. Perhaps it would
> > be helpful to also have some ant script to build a lift project? ...
> > or perhaps have a downloadable zip archive from lift's site that
> > contains incipient projects like the results produced by Lift's
> > archetypes? ... so that people can just download that project zip file
> > with the ant build in it and then start building the app on top of
> > that? ... would that work ?
>
> Nice angle!
> Or perhaps have an online service where you can specify the archetype
> details and have a compressed payload downloaded?

Yup crossed my mind ... and I love it. Basically run the archetype on
demand and serve back the zip content.

[João Pereira]

yeah. nice service. maybe built with lift?

--
João Miguel Pereira, PMP
http://jpereira.eu
http://www.linkedin.com/in/joaomiguelpereira
joaomigue...@gmail.com

[Timothy Perrett]

Perhaps we could couple this with Hudson? Hudson has an API (see here:
http://wiki.hudson-ci.org/display/HUDSON/Remote+access+API ) so
perhaps we could serve stuff up on the fly through that? Just
spitballing here....

Cheers, Tim

[marius d.]

sounds good to me

On Apr 14, 10:58 pm, Timothy Perrett <timo...@getintheloop.eu> wrote:
> Perhaps we could couple this with Hudson? Hudson has an API (see here:http://wiki.hudson-ci.org/display/HUDSON/Remote+access+API) so

[tk050305cnx]

On Apr 14, 7:53 pm, TylerWeir <tyler.w...@gmail.com> wrote:
>
> You'll have a better experience if you take the time to learn how
> maven works.

Perhaps. But, it's a bit like this:

"Can I have a beer, please."
"We don't have beer right now, but I think you would have a better
experience with our own brand whiskey."

Never mind. I can't get it to work right now. I know how to write
servlets and filters directly, so that may be the easier approach for
me. I'll certainly check in again later.

Thanks & keep up the good work,
CNX

[Timothy Perrett]

Perhaps David B can help on the feasibility of this with our current hudson
install / services.

Cheers, Tim

[Josh Suereth]

Does the ant build file already exist?  If not, it wouldn't be too hard to create a maven assembly that "assembles" all the various dependencies and such into a directory (or uses something like the maven-ant-tasks to materialize them for the project later), and includes an ant build script/starter project code.   I can add this to my list of things todo, however if someone else is interested and has time, I'm more than willing to help answer questions / point you in the correct maven direction. 

I guess it would be ideal to make use of the current archetypes, but I don't even see this as necessary.  An assembly for a zip/tgz file could be generated which includes a project-starter kit for ANT and could be deployed into the maven repository with all the other artifacts for a build.   This could be downloaded from the maven repository then (and versioned, etc.).  We actually use this at work for our "ubiquituous" install (we also have RPMs, etc. for installing our software).

My question here, is why should the project be generated on the fly?  Is that so you can have your desired package structure on startup?


-Josh

[David Pollak]

On Tue, Apr 14, 2009 at 8:52 PM, tk050305cnx <tk050...@gmail.com> wrote:

On Apr 14, 7:53 pm, TylerWeir <tyler.w...@gmail.com> wrote:
>
> You'll have a better experience if you take the time to learn how
> maven works.

Perhaps. But, it's a bit like this:

"Can I have a beer, please."
"We don't have beer right now, but I think you would have a better
experience with our own brand whiskey."

You know... it's more like:

"I want all of you hundreds of people who have successfully used Lift with Maven to stop what you're doing and pay attention to me and throw out your work and do things my way."

While we are a community that welcomes newbies and tries to work with as many different people and with as many different styles as possible, there are things that we've collectively learned.  We've found that Maven is preferable for our style of development.  If you want to use Ant, there's nothing stopping you and we'd welcome some Ant scripts for building Lift, but we're not going to stop what we're doing and write one for you just because you demand that we do so.  Please go back and write the Ant scripts yourself and contribute to the community rather than being rude to us because we don't do things the way you want.  That will demonstrate that you are willing to contribute in rather than demand and insult when your demands are not met.
 

Never mind. I can't get it to work right now. I know how to write
servlets and filters directly, so that may be the easier approach for
me. I'll certainly check in again later.

Thanks & keep up the good work,

CNX

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

[Alexander Kellett]

which would also make
http://code.google.com/p/simple-build-tool/wiki/WebApplicationExample
much much more interesting to me...

Alex

[Alexander Kellett]

On Wed, Apr 15, 2009 at 5:26 PM, David Pollak
<feeder.of...@gmail.com> wrote:
> While we are a community that welcomes newbies and tries to work with as
> many different people and with as many different styles as possible, there
> are things that we've collectively learned.  We've found that Maven is
> preferable for our style of development.  If you want to use Ant, there's
> nothing stopping you and we'd welcome some Ant scripts for building Lift,
> but we're not going to stop what we're doing and write one for you just
> because you demand that we do so.  Please go back and write the Ant scripts
> yourself and contribute to the community rather than being rude to us
> because we don't do things the way you want.  That will demonstrate that you
> are willing to contribute in rather than demand and insult when your demands
> are not met.

many people are scared by maven. myself included after my previous
"fun" with getting lift working.

is there a way to get a self contained "hello world" zip up on github
if it is not already there? afaiu maven also allows for local caches,
could that that be placed in the zip, or is it simply too big?

i think that might scare people much less than pasting the very opaque
four liner which asks questions i do not know the answer to :)

Alex

[Timothy Perrett]

Alex,

We could do something like this, but it would still need to use maven to
start the server (mvn jetty:run). Unfortunately, you'll need to have a local
maven repo, that's a) part of how maven works and b) the legal implications
of us redistributing a bunch of other peoples code to make it self contained
probably had various ramifications.

We could supply a hello world on github, but this is just what the archetype
creates for you. Perhaps this is a case of education in our community about
how maven works? If there were supporting documentation would it be so
scary? (it might help you answer mvn's questions too!)

Cheers, Tim

[Alexander Kellett]

from what i can see the latest sbt supports jetty-run command :)
testing it out now!
next step, write a command for it to perform the equiv of mvn idea:idea.

Alex

[Alexander Kellett]

looks like it works
"Welcome to hello-lift at Wed Apr 15 20:17:44 CEST 2009"

:)

Alex

[David Pollak]

I am all in favor of an Ant build script or an SBT-based build script.  Both would be great contributions.  I do not have time for them, but anyone out there who has skills with Ant and/or SBT, I'll buy you a beer or two if you spend a couple of hours putting together examples.

My rant is against the attitude that somehow the Lift community should instantly change its priorities because one person has a different perspective on things.  We are not waiters in a restaurant.  We are not serving peoples whims.  We are a collaborative community.  Anybody who treats the folks in this community as wait-staff fundamentally misunderstands the ethos of the Lift community.

The Lift community is a place that I like being because almost everybody is willing to roll up their sleeves and help.  Marius, Derek, Tyler, Charles, Jorge, Tim, etc. roll up their sleeves and help all comers.  Each of these guys can be making more money and/or spending time with their friends and family rather than helping newbies, but when they came to the community, they were newbies and I helped them and they have perpetuated that spirit.  Newbies help us by asking questions, by learning Lift, by making suggestions, by contributing code, and ultimately by helping other newbies.  We welcome different perspectives, but we do not welcome insulting attitudes.

Had the conversation gone more along the lines of "any chance you'll change your priorities to support Ant?" "Not for 1.1, but perhaps you can help." "I can write Ant Scripts, but I need some guidance about the dependencies..." The poster would have gotten what he wanted and the whole Lift community would have benefited.

So, yes, I am in favor of lots of different build options.  Are committers, we have limited time and will officially support Maven.  If someone else comes along and demonstrates Ant, SBT, etc. support and sticks with it for a while, they might become the owner of that build system and a Lift committer.

Thanks,

David

 

Alex

[Alexander Kellett]

attached a replacement for the sbt script provided, with inline
comments for getting it to work. barely tested and trivial. not yet
verified that this works without a preexisting maven install. will
automate more at weekend.

will look into getting the blocking-on-page-load modification into
sbt/lift somehow also given that it has its own continuous compile
system.

On Thu, Apr 16, 2009 at 3:57 PM, David Pollak

[Mark Harrah]

Hi,

Thanks for putting effort into this. The inline dependency
declarations replace the pom.xml, so it isn't needed. You can also
declare the archetype as a dependency and extract and process it. I
have attached a project definition that does not require downloading
the zip manually or processing with sed (it does require sbt, of
course).

Put it in 'project/build/src' directory in your new project directory. Then do:
$ sbt
bootstrap
jetty-run

(fill in the name and other info when prompted)

Thanks again,
-Mark

[Alexander Kellett]

excellent, thanks for finishing this off mark! is it possible this
might get into a later sbt release or does this belong somewhere in
the lift source tree?

thank you!
Alex

[Sean Reque]

I am a newcomer to Scala and Lift, and I plan on trying to figure out
how to use either Buildr or Raven, to run Lift, and if I can
successfully do so I will try to share my work. If I cannot, I will
probably stop pursuing Lift and start looking at other areas of Scala.
I say this simply to state you will drive many potential users of Lift
away by enforcing the use of Maven without even giving sufficient
documentation to allow other build tools to be used. I cannot see any
productivity gain from any web framework over other existing
competitors that could offset the productivity loss from using Maven.

[Alexander Kellett]

hey sean,

i hope you're open to other possibilities than buildr/raven :)
i myself have no real interest in messing with maven after my terrible
experiences from when i was working on java code full time..
i just verified that it takes just a few minutes to install sbt and
get a running lift app :)
you can find the things needed in Marks Harrah's reply to this thread
and sbt can be found at http://code.google.com/p/simple-build-tool/

hope this helps,
Alex

[Josh Suereth]

On Thu, Apr 16, 2009 at 10:40 PM, Sean Reque <sean...@gmail.com> wrote:

I am a newcomer to Scala and Lift, and I plan on trying to figure out
how to use either Buildr or Raven, to run Lift, and if I can
successfully do so I will try to share my work. If I cannot, I will
probably stop pursuing Lift and start looking at other areas of Scala.
I say this simply to state you will drive many potential users of Lift
away by enforcing the use of Maven without even giving sufficient
documentation to allow other build tools to be used. I cannot see any
productivity gain from any web framework over other existing
competitors that could offset the productivity loss from using Maven.

Wow, strong words.  I'm wondering what it was about maven that caused this productivity loss?  So far my shop has not run into this, in fact, we've had the opposite vs. Ant.  Granted, Raven and Buildr are different beasts. 

I posted a blog article earlier on how to use the scala maven infrastructure + the maven-ant-tasks to bootstrap a scala project.  I think the same would be possible if you wanted to use Lift with ant, and (AFAIK) easier in Buildr or Raven (as I believe they support Ivy/Maven repo materialization directly).  Perhaps I'll spend some time and make an ant file that you can raven-ify or buildr-ize.  What would you need to be able to get Buildr or Raven up and working?


In the meantime, if maven is keeping you from contributing/working with lift, then that's your loss.


-Josh

[Josh Suereth]

Here's a decent start for an ant build.  If anyone is interested in helping flesh out this build file more, let's start up a github project/node and crank it out. 

Note: This will compile a lift project (I only tested with an archetype), but not package or anything else.

-Josh

[Jeppe Madsen]

On Fri, Apr 17, 2009 at 10:21 AM, Alexander Kellett <lyp...@gmail.com> wrote:

hey sean,

i hope you're open to other possibilities than buildr/raven :)
i myself have no real interest in messing with maven after my terrible
experiences from when i was working on java code full time..
i just verified that it takes just a few minutes to install sbt and
get a running lift app :)
you can find the things needed in Marks Harrah's reply to this thread
and sbt can be found at http://code.google.com/p/simple-build-tool/

I'm also not very keen on using maven for my builds but I think it's
fine as a black box tool for generating artifacts.

Recently, we've moved all our Ant builds to Gradle which has been a
(mostly) pleasant experience. It has dependency management (and can
use maven repos) but you use a Groovy DSL to specify your build.

There's a patch to make Gradle work with scala apps (haven'tried it),
but I was wondering if anybody has used it for Scala or even Lift?

/Jeppe

[Mark Harrah]

Well, maybe the archetype code could be generalized and go into sbt. We can
continue discussing that on the sbt mailing list if you are interested. The
remaining part is just dependency declarations for the hello-lift example.

Thanks,
Mark

[David Pollak]

On Thu, Apr 16, 2009 at 7:40 PM, Sean Reque <sean...@gmail.com> wrote:

I am a newcomer to Scala and Lift, and I plan on trying to figure out
how to use either Buildr or Raven, to run Lift, and if I can
successfully do so I will try to share my work. If I cannot, I will
probably stop pursuing Lift and start looking at other areas of Scala.
I say this simply to state you will drive many potential users of Lift
away by enforcing the use of Maven without even giving sufficient
documentation to allow other build tools to be used.

Ummm...

What kind of documentation beyond "put the Lift JAR files along with the Scala library in WEB-INF/lib directory" is necessary?  Lift is not magic.  We're not doing anything complex.
 

I cannot see any
productivity gain from any web framework over other existing
competitors that could offset the productivity loss from using Maven.

From time to time, the "I hate Maven" thread comes up.  To date, nobody has demonstrated any real problems with Maven and Lift.  Yeah, sure, sometimes when a repository is down, life is a bit of a challenge.  Other than that, I have not seen any more problems with Maven than with any of the other tools I commonly use (e.g., Windows and Mac OS X fail far more frequently than Maven.)  If you have specific issues related to Maven and Lift, I'm all for hearing about them.

Also, you might try using SBT... as you can see from this thread, folks are making Lift and SBT play well together (woo hoo!)

Thanks,

David

On Apr 14, 6:53 am, TylerWeir <tyler.w...@gmail.com> wrote:

> > expected output. I don't want to bother with Maven at this time. Can
>
> You'll have a better experience if you take the time to learn how
> maven works.
>
> On Apr 14, 7:11 am, tk050305cnx <tk050305...@gmail.com> wrote:
>
> > I am new to Liftweb. Unfortunately, the example app in the "getting
> > started" doc did not work. That is... Maven did not produce the
> > expected output. I don't want to bother with Maven at this time. Can
> > you point me to a source that describes how to set up a helloworld
> > type of application manually and deploy it on Tomcat? Is there any
> > Eclipse automation for that?
>
> > Cheers, CNX

[Sean Reque]

> Wow, strong words.  I'm wondering what it was about maven that caused this
> productivity loss?  So far my shop has not run into this, in fact, we've had
> the opposite vs. Ant.  Granted, Raven and Buildr are different beasts.

I apologize for the strong words. I think I was still angry from
reading some of David Pollack's strong negative comments about Ruby in
other mailing list posts(for example,
http://markmail.org/message/2chixvplljdjpogc#query:scala%20lift%20with%20buildr+page:1+mid:7f74nyoyanxq2kir+state:results),
and some of that anger got funneled into my post. That said, I have
long thought that a DSL based inside of a general purpose scripting
language is always going to be far more productive than a DSL based in
XML (http://www.martinfowler.com/articles/rake.html,
http://blog.labnotes.org/2007/04/18/introducing-buildr-or-how-we-cured-our-maven-blues/).
Before I felt so strongly against maven, however, I also had the
privilege of using it and found that our team was spending far too
much time dealing with our build system. We could not find the
documentation we needed, debugging was difficult, and programming in
Jelly just isn't as productive as programming in full scripting
languages like perl/python/ruby/groovy/<insert-favorite-language-
here>. I thought that Maven was as more unwieldy than Ant as it was
more powerful.

That said, using buildr did not go flawlessly either. The main issues,
however, were not buildr itself, but getting it's jetty plugin to
work. I'm guessing that buildr does not have nearly the backing in the
Java community as Maven, which is a pity. Finally, I have not tried
SBT, but I will look into it as well. My main goal, though, is to try
out lift!

I am inlining the buildr buildfile I created for Lift's hello world
example below.


#!/usr/bin/ruby
require 'buildr/scala'
require 'buildr/java'

=begin
Differences between maven pom.xml and this buildr file:

1. I could not get buildr to build this project without setting
my environment variable SCALA_HOME to point to my scala
distribution.
2. Many jars had to be specified manually that did not need not
specified in the maven pom.xml
3. They jetty plugin seems to force it's own version, 6.1.3, though
the
source code documentation tauntingly suggests a way to specify
your own version

To run the example:
buildr helloworld:run
=end
VERSION_NUMBER = "1.0.0"
GROUP = "helloworld"

repositories.remote << "http://www.ibiblio.org/maven2/"
repositories.remote << "http://scala-tools.org/repo-releases"

Artifacts = struct(
:scala => group('scala-library', 'scala-compiler', :under =>
"org.scala-lang",
:version => "2.7.3"),
:lift => group('lift-util', 'lift-webkit', 'lift-mapper', :under =>
"net.liftweb",
:version => "1.0"),
:servlet => "javax.servlet:servlet-api:jar:2.5",
:junit => "junit:junit:jar:4.5",
:jetty => group("jetty", "jetty-util", "servlet-api-2.5", "jsp-2.1",
"jsp-api-2.1",
:under => "org.mortbay.jetty", :version => "6.1.6"), #cannot get
range syntax to work
:log4j => "log4j:log4j:jar:1.2.14",
:commons => "commons-fileupload:commons-fileupload:jar:1.2.1"
)

JettyJSP = Artifacts.jetty.select {|jar| jar.name =~ /jsp/ }
JettyServlet = Artifacts.jetty.find {|jar| jar.name =~ /servlet/ }

#hack to force my own version of jetty to load
Java.classpath.concat Artifacts.jetty.map {|a| a.to_spec}
require 'buildr/jetty'

desc "The HelloWorld project"
define "helloworld" do

project.version = VERSION_NUMBER
project.group = GROUP

compile.with [:lift, :servlet, :junit, :jetty].map {|sym|
Artifacts.send sym }

package(:war).with :libs => [:scala, :lift, :log4j, :commons].map { |
sym|
Artifacts.send sym } + [JettyJSP, JettyServlet ]

=begin
this does not work. The war file never seems to get deployed.
jetty.use package(:war) do
jetty.deploy("#{jetty.url}/". package(:war))
end
task :run => "jetty:use"
=end

#workaround for the commented-out code above
task :run => package(:war) do
jetty = Buildr::Jetty.new("jetty", "http://localhost:8080")
jetty.send :fire #method is protected
jetty.deploy "#{jetty.url}/", package(:war)
sleep
end
end

[Josh Suereth]

Maven does not really use Jelly anymore (in Maven2).  I agree a Maven1 was rather ridiculous.  Maven2 takes the idea that the pom should just be configuration + declaration, not implementation details.  It's a breath of fresh air from other build tools (even Maven1).  The issue still becomes how do you implement "plugins" so as to keep the "declare, don't implement" rules.   I would recommend just looking at the general idea, because it will change your opinion of build tools.  It still has a long way to come, but the idea of it, I think, has a lot of potential, more so than task-based build utilities.


-Josh

[Alex Boisvert]

Hi Sean,

I've been using Lift + Buildr for a while now and I'm pretty happy with both.

See some comments below.

On Mon, Apr 20, 2009 at 5:53 AM, Sean Reque <sean...@gmail.com> wrote:

=begin
Differences between maven pom.xml and this buildr file:

1.  I could not get buildr to build this project without setting
   my environment variable SCALA_HOME to point to my scala
distribution.

This is a documented requirement for the Buildr Scala support.  
http://buildr.apache.org/languages.html#scala

Unlike the Maven2 plugin, Buildr relies on your local Scala installation instead of downloading the Scala jars from a repo.  Both approaches have advantages/disadvantages.
 

2.  Many jars had to be specified manually that did not need not
specified in the maven pom.xml

Correct, Buildr does not yet support transitive dependencies, so you have to specify all dependencies explicitly.

3.  They jetty plugin seems to force it's own version, 6.1.3, though
the  source code documentation tauntingly suggests a way to specify
your own version

Did you try adding "build.yml" next to your Buildfile with "jetty: 6.1.15" in it?

I tend to use an external Jetty with an exploded war.   I find this easier to setup a separate Jetty configuration (e.g., memory, environment, datasources, commons jars, javarebel, etc.) and basically use the same environment for development and production.

I also have a fork of Lift where I builld everything through buildr, although some tests still fail (I believe mostly related to Jetty continuations so must be an environment setup issue) and I still have a push a few things to it...  Not enough time right now to play with Lift...

alex

[Jeppe Nejsum Madsen]

On Mon, Apr 20, 2009 at 2:53 PM, Sean Reque <sean...@gmail.com> wrote:

[...]
 

I am inlining the buildr buildfile I created for Lift's hello world
example below.

 
[..]

I recently did the same for Gradle (it does require building Gradle from source to get the Scala plugin). This is the result:

usePlugin('scala')
usePlugin('war')
usePlugin('jetty')

targetCompatibility = 1.5
version = 1
jettyRun.scanIntervalSeconds=5

dependencies {
    addMavenRepo()
    addMavenStyleRepo('scala-releases', 'http://scala-tools.org/repo-releases/')

    scalaTools 'org.scala-lang:scala-compiler:2.7.3',
    'org.scala-lang:scala-library:2.7.3'

    compile 'org.scala-lang:scala-library:2.7.3',
        'net.liftweb:lift-webkit:1.0',
    'net.liftweb:lift-util:1.0'
   
    testCompile 'junit:junit:4.4',
        'org.scala-lang:scala-compiler:2.7.3',
        'org.mortbay.jetty:jetty:6.1.6'
   
    testCompile 'org.mortbay.jetty:jetty-util:6.1.6'
   
    providedCompile 'javax.servlet:servlet-api:2.5'
}

It works for compiling, test, generating wars and running jetty....

/Jeppe