Hi Richard, If it would be possible to use SBT with Apache Hudson and would be no other problems I think it's possible to use it as a replacement for Maven. But I think that we should expect some problems even for local builds.
2010/12/23 Richard Hirsch <[email protected]> > I have no problem using sbt. > > I think the main question is whether Apache Hudson would be able to > support the set-up described in the blog that Vassil mentioned. > > The only reason we would have to maintain maven is if sbt doesn't work > on the Apache Hudson. > > D. > > On Wed, Dec 22, 2010 at 9:26 PM, Vassil Dichev <[email protected]> wrote: > > Hey Vladimir, > > > > I have thought about this, but since we've started with maven, there > > was usually more benefit investing in other features than in a build > > tool transition. For a while continuous compilation worked even with > > the maven plugin > > (http://scala-tools.org/mvnsites/maven-scala-plugin/usage_cc.html), > > although lately it never seemed to work for some reason. > > > > SBT does have some advantages, and Lift is also trying to migrate. I > > also can't help but like the fact that SBT, just like ESME, has > > Actions ;-) > > http://code.google.com/p/simple-build-tool/wiki/CustomActions > > > > Hudson integration is a good point you've mentioned, and this is what > > I was able to find: > > http://henkelmann.eu/2010/11/14/sbt_hudson_with_test_integration > > > > One question: does it make sense to maintain Maven if/when we move to > > SBT? I guess not. > > > > It's nice that you're giving some thought to this, and even better > > that you've prepared a build file already! It might definitely be > > beneficial to test out this setup, and I don't consider your mail a > > spam :) > > > > Vassil > > > > > > On Wed, Dec 22, 2010 at 9:50 PM, Vladimir Ivanov <[email protected]> > wrote: > >> Hi all, > >> > >> Have you, guys, considered building ESME with Simple Build Tool: > >> http://code.google.com/p/simple-build-tool/ , at least locally? > >> > >> SBT has several pros and cons. > >> > >> Pros: > >> > >> - Native Scala support -> no Scala plugin > >> - There is no need to recompile all project files, only changed ones -> > more > >> faster build&run > >> - Buildfile is written in Scala instead of verbose XML -> buildfile is > >> shorter > >> > >> Cons: > >> > >> - SBT is based on Apache Ivy (while it includes Maven repo by default > and > >> can access local Maven repo) > >> - I have no idea whether integration of SBT with VCS and CI tools is > >> possible > >> > >> Probably many more cons exist > >> > >> I managed to build, run tests and run ESME app on jetty with SBT (of > course > >> I was able to perform only minimal testing). As an example, here is my > SBT > >> project file below: > >> > >> import sbt._ > >> > >> class EsmeProject(info: ProjectInfo) extends DefaultWebProject(info) { > >> val liftVersion = "2.2-RC4" > >> val compassVersion = "2.1.1" > >> val luceneVersion = "2.4.0" > >> > >> val mavenLocal = "Local Maven Repository" at > >> "file://"+Path.userHome+"/.m2/repository" > >> > >> val scalatoolsSnapshot = ScalaToolsSnapshots > >> val compassRepo = "Compass Repository" at " > http://repo.compass-project.org > >> " > >> val twitterRepo = "Twitter Repository" at "http://maven.twttr.com"; > >> > >> def extraResources = "LICENSE" +++ "NOTICE" > >> override def mainResources = super.mainResources +++ extraResources > >> > >> override def ivyXML = > >> <dependencies> > >> <dependency org="net.lag" name="configgy" rev="2.0.1"> > >> <exclude org="org.scala-tools" module="vscaladoc"/> > >> </dependency> > >> <dependency org="com.twitter" name="ostrich" rev="2.3.2"> > >> <exclude org="org.scala-tools" module="vscaladoc"/> > >> </dependency> > >> </dependencies> > >> > >> override def libraryDependencies = Set( > >> "net.liftweb" %% "lift-util" % liftVersion % "compile->default", > >> "net.liftweb" %% "lift-webkit" % liftVersion % "compile->default", > >> "net.liftweb" %% "lift-widgets" % liftVersion % "compile->default", > >> "net.liftweb" %% "lift-mapper" % liftVersion % "compile->default", > >> "net.liftweb" %% "lift-testkit" % liftVersion % "compile->default", > >> "net.liftweb" %% "lift-openid" % liftVersion % "compile->default", > >> "net.liftweb" %% "lift-actor" % liftVersion % "compile->default", > >> "net.liftweb" %% "lift-json" % liftVersion % "compile->default", > >> "net.liftweb" %% "lift-common" % liftVersion % "compile->default", > >> "org.compass-project" % "compass" % compassVersion % > "compile->default", > >> "org.apache.lucene" % "lucene-core" % luceneVersion % > >> "compile->default", > >> "org.apache.lucene" % "lucene-snowball" % luceneVersion % > >> "compile->default", > >> "commons-httpclient" % "commons-httpclient" % "3.1" % > >> "compile->default", > >> "org.apache.derby" % "derby" % "10.5.3.0_1" % "compile->default", > >> "org.mortbay.jetty" % "jetty" % "[6.1.6,)" % "test->default", > >> "junit" % "junit" % "3.8.1" % "test->default", > >> "junit" % "junit" % "4.4" % "test->default", > >> "log4j" % "log4j" % "1.2.16" % "compile->default", > >> "org.slf4j" % "slf4j-api" % "1.6.1" % "compile->default", > >> "org.slf4j" % "slf4j-log4j12" % "1.6.1" % "compile->default", > >> "org.scala-tools.testing" %% "specs" % "1.6.6" % "test->default" > >> ) ++ super.libraryDependencies > >> } > >> > >> > >> Of course I didn't add many infrastructural tags comparing with Maven > pom. > >> > >> I thought that this might be interesting for someone or may be somebody > >> would wish to share any ideas, make any suggestions, comments etc. > Otherwise > >> please consider it as a spam. > >> > >> -- > >> Best Regards, > >> Vladimir Ivanov > >> > > > > > > > > -- > > Twitter: http://twitter.com/vdichev > > Blog: http://speaking-my-language.blogspot.com > > > -- Best Regards, Vladimir Ivanov
