> Wow, strong words. I'm wondering what it was about maven that caused this > productivity loss? So far my shop has not run into this, in fact, we've had > the opposite vs. Ant. Granted, Raven and Buildr are different beasts.
I apologize for the strong words. I think I was still angry from reading some of David Pollack's strong negative comments about Ruby in other mailing list posts(for example, http://markmail.org/message/2chixvplljdjpogc#query:scala%20lift%20with%20buildr+page:1+mid:7f74nyoyanxq2kir+state:results), and some of that anger got funneled into my post. That said, I have long thought that a DSL based inside of a general purpose scripting language is always going to be far more productive than a DSL based in XML (http://www.martinfowler.com/articles/rake.html, http://blog.labnotes.org/2007/04/18/introducing-buildr-or-how-we-cured-our-maven-blues/). Before I felt so strongly against maven, however, I also had the privilege of using it and found that our team was spending far too much time dealing with our build system. We could not find the documentation we needed, debugging was difficult, and programming in Jelly just isn't as productive as programming in full scripting languages like perl/python/ruby/groovy/<insert-favorite-language- here>. I thought that Maven was as more unwieldy than Ant as it was more powerful. That said, using buildr did not go flawlessly either. The main issues, however, were not buildr itself, but getting it's jetty plugin to work. I'm guessing that buildr does not have nearly the backing in the Java community as Maven, which is a pity. Finally, I have not tried SBT, but I will look into it as well. My main goal, though, is to try out lift! I am inlining the buildr buildfile I created for Lift's hello world example below. #!/usr/bin/ruby require 'buildr/scala' require 'buildr/java' =begin Differences between maven pom.xml and this buildr file: 1. I could not get buildr to build this project without setting my environment variable SCALA_HOME to point to my scala distribution. 2. Many jars had to be specified manually that did not need not specified in the maven pom.xml 3. They jetty plugin seems to force it's own version, 6.1.3, though the source code documentation tauntingly suggests a way to specify your own version To run the example: buildr helloworld:run =end VERSION_NUMBER = "1.0.0" GROUP = "helloworld" repositories.remote << "http://www.ibiblio.org/maven2/" repositories.remote << "http://scala-tools.org/repo-releases" Artifacts = struct( :scala => group('scala-library', 'scala-compiler', :under => "org.scala-lang", :version => "2.7.3"), :lift => group('lift-util', 'lift-webkit', 'lift-mapper', :under => "net.liftweb", :version => "1.0"), :servlet => "javax.servlet:servlet-api:jar:2.5", :junit => "junit:junit:jar:4.5", :jetty => group("jetty", "jetty-util", "servlet-api-2.5", "jsp-2.1", "jsp-api-2.1", :under => "org.mortbay.jetty", :version => "6.1.6"), #cannot get range syntax to work :log4j => "log4j:log4j:jar:1.2.14", :commons => "commons-fileupload:commons-fileupload:jar:1.2.1" ) JettyJSP = Artifacts.jetty.select {|jar| jar.name =~ /jsp/ } JettyServlet = Artifacts.jetty.find {|jar| jar.name =~ /servlet/ } #hack to force my own version of jetty to load Java.classpath.concat Artifacts.jetty.map {|a| a.to_spec} require 'buildr/jetty' desc "The HelloWorld project" define "helloworld" do project.version = VERSION_NUMBER project.group = GROUP compile.with [:lift, :servlet, :junit, :jetty].map {|sym| Artifacts.send sym } package(:war).with :libs => [:scala, :lift, :log4j, :commons].map { | sym| Artifacts.send sym } + [JettyJSP, JettyServlet ] =begin this does not work. The war file never seems to get deployed. jetty.use package(:war) do jetty.deploy("#{jetty.url}/". package(:war)) end task :run => "jetty:use" =end #workaround for the commented-out code above task :run => package(:war) do jetty = Buildr::Jetty.new("jetty", "http://localhost:8080") jetty.send :fire #method is protected jetty.deploy "#{jetty.url}/", package(:war) sleep end end --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---