buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shane Witbeck <sh...@digitalsanctum.com>
Subject Re: buildr usability
Date Tue, 20 Oct 2009 16:52:38 GMT
+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 <mat@schaffer.me> 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" <ittay.dror@gmail.com> 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.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>

Mime
View raw message