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 >
