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
>>>
>>
>
