+1. I actually suggested this a long time ago but it was at a time when JRuby compatibility wasn't there yet. I have been leading the effort of using Buildr for my team (and have been for about 1.5 years) and much of what the OP says about obstacles sounds very familiar.
-Shane On Tue, Oct 20, 2009 at 9:58 AM, Mat Schaffer <[email protected]> wrote: > I don't think the JVM startup is that much of an issue especially > considering that we're comparing buildr to ant and maven which also incur > similar start-up delays. +1 for a simple unzip-and-run installation. > -Mat > > On Oct 20, 2009, at 9:41 AM, Daniel Spiewak wrote: > >> This is a really great idea! I'm actually surprised that none of us >> thought of this earlier. JRuby is very easy to distribute in a >> self-contained fashion, so this sort of packaging is not only possible but >> very natural. The only disadvantage would be the performance hit carried by >> JRuby and really the JVM's slow startup. I think this is probably >> palletable though, especially given the convenience of this approach. >> >> Daniel >> >> On Oct 20, 2009, at 7:47 AM, "Ittay Dror" <[email protected]> wrote: >> >>> Hi, >>> >>> >>> Regarding the next buildr version, I think the biggest issue should be >>> being able to quickly start using buildr. >>> >>> >>> My experience is that BuildR is great for me as a build developer. It >>> allows me to do in several lines of code things that would take a lot >>> more in Ant and that I probably wouldn't even try with Maven. >>> >>> >>> However, when it comes to other developers that just want to compile the >>> code, the procedure to start working with BuildR is just an obstacle >>> they need to go through. And given that it is not as standard as Maven >>> or Ant, it is something new to install. >>> >>> >>> Right now, I have 3 people trying to use BuildR without success. The >>> first uses linux and so installed the ruby package but had segmentation >>> faults with java 1.6 (which we must use), so he needed to compile ruby >>> from source (not a smooth experience for a java developer coming from >>> windows). After compiling and installing, trying to upload, he got an >>> error about not being able to require openssl. Now, 'require' is not a >>> known term to a java developer... the reason for the error was that at >>> the time of compilation he didn't have libssl-dev installed. So he >>> needed to install it, re-generate the Makefile for ext/openssl and then >>> install it. This was a long, un-Java process to go through... >>> >>> >>> Two other users had issues because they couldn't get BuildR to install >>> on Mac. RJB could not find the ruby headers. We couldn't resolve this >>> issue, so they needed to resort to using another machine (!) >>> >>> >>> Of course there's the choice of using JRuby. However, It will still >>> require multiple steps (installing jruby then buildr) and I'm sure it >>> will have its own issues. >>> >>> >>> What it boils down to is bad first impression with BuildR. >>> >>> I want to suggest that BuildR will be provided as a self-contained >>> package. It could be jruby with all gems that can be extracted some >>> placed and used, but optimally, it will also be packages per OS (can be >>> .tar.gz of binaries), which will help performance when running the >>> builds. An additional feature is proper inspection of the environment >>> before running (something like 'require 'openssl' rescue puts "please >>> make sure you have openssl installed, on linux install libssl and on >>> mac..."). >>> >>> Regards, >>> Ittay >>> >>> P.s., I can try to accomplish this if the idea sounds good. >>> >>> >>> >>> >>> >>> >>> >>> > >
