Um ... awesome! :-) +1 to making SBT a build option.
I think there is something to be said for offering both. For developers and the "cool kids", SBT is probably preferable. (Did I read that SBT can force recompilation of subclasses of modified classes? Because that has been killing me working on the Comet stuff.). For Hudson integration and "enterprise" shops who might be thinking about deploying ESME I'm betting Maven is more widespread. These are just feelings without much actual data or experience behind them. Interested if others feel, or know, differently. I would definitely support checking in the SBT build file to the trunk. I would switch to using SBT for my development activities. Ethan On Wed, Dec 22, 2010 at 10:45 PM, Richard Hirsch <[email protected]> wrote: > 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 >> >
