Hello Imtiaz, Thank you for comments!
I didn't insist that SBT would be an immediate replacement for Maven. Of course, Maven is widely adopted and recognized project management tool. Moreover, it is not clear whether SBT integrates well with Apache Hudson. Initially I thought that SBT might help developers to perform their tasks locally faster and more comfortable, and affect on their productivity due to some advantages it brings to build process. If other guys would find SBT useful, I think it's worth considering. Obiously, the drawback here is that two independent build tools should be maintained. Btw, SBT is based on Apache Ivy - also Apache-hosted, open and popular dependency management tool. SBT just provides developer opportunity to work with dependencies in Scala code, which is IMHO much more comfortable to deal with (considering that ESME is Scala based project) comparing to verbose XML. But you are right, introduction of new tool contains an element of risk. 2010/12/24 Imtiaz Ahmed H E <[email protected]> > Just wondered, should we move to SBT, even if only as an 'extra' apart > from Maven, right now. > > It only means diversion of scarce programming resources like Ivanov for a > while, towards getting this stable. > > In the past PubSubHubub has appeared abandoned by Google a while after > initiation. > > I hope the same fate does not befall SBT, a Google code project. > > Though of course SBT has significant & prominent aficionados in the Scala > community. > > Unless something is supported openly by an organization like Apache (Maven) > or is a more apparently widely adopted project like Lift we should err on > the side of caution. > > Imtiaz > > > ----- Original Message ----- From: "Ethan Jewett" <[email protected]> > To: <[email protected]> > Sent: Friday, December 24, 2010 4:14 PM > Subject: Re: SBT with ESME > > > > Hi all, > > This has been committed but I'm getting a huge number of compile > errors. I'm not sure if this is because my local sbt setup is a bit > messed up at the moment (it is definitely messed up, so that could be > the problem) or because there is something missing from the files, so > I committed to the Lift 2.2 branch with the hope that someone else > will be able to try it out. > > I think I have successfully told SVN to ignore all the generated SBT > files, but if you are using SBT please do an "svn status" and take a > look the first few times you commit after building. > > I will be mostly without internet for the next week+, so I wish you > all a happy holiday season and I look forward to working more with > everyone next year! > > Thanks! > Ethan > > On Thu, Dec 23, 2010 at 4:34 PM, Richard Hirsch <[email protected]> > wrote: > >> Looks great. >> >> I'm going to be on vacation for the next two weeks and might not have >> Internet access. If some other committer could commit Vladimir's >> patches to the 2.2 branch that would be great >> >> Wishing the Apache ESME Community Happy Holidays. >> >> Thanks. >> >> D. >> >> On Thu, Dec 23, 2010 at 12:40 PM, Vladimir Ivanov <[email protected]> >> wrote: >> >>> Richard &all, >>> >>> I've added ESME-320 issue with basic files attached. So you are welcome >>> to >>> test it locally. >>> >>> 2010/12/23 Richard Hirsch <[email protected]> >>> >>> @Vladimir why don't you create a JIRA item for the SBT integration >>>> and post your code to that JIRA item. >>>> >>>> D. >>>> >>>> On Thu, Dec 23, 2010 at 8:49 AM, Ethan Jewett <[email protected]> >>>> wrote: >>>> > 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 >>>> >>> >>>> >> >>>> > >>>> >>>> >>> >>> >>> -- >>> Best Regards, >>> Vladimir Ivanov >>> >>> >> > -- Best Regards, Vladimir Ivanov
