On Mon, Oct 6, 2008 at 12:24 PM, Victor Hugo Borja <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 6, 2008 at 2:01 PM, Assaf Arkin <[EMAIL PROTECTED]> wrote:
>
>> On Mon, Oct 6, 2008 at 11:46 AM, <[EMAIL PROTECTED]> wrote:
>> > - runner.gems.update 'rspec' => '>0'
>> > + runner.gems.update 'rspec' => '>= 1.1.5'
>>
>> This is guaranteed to fail when you get a new version of RSpec via gem
>> update, but it's broken/breaking, yet gets picked up for being newer
>> than 1.1.5. For example, on my machine it picks RSpec 1.1.8.
>>
>> If this is happening in the forked process, you can get all the right
>> dependencies set up at once by doing:
>>
>> gem 'buildr', {Buildr::VERSION}
>
>
> That rspec requirement happens on he jtestr process (a new JRuby runtime),
> buildr isn't loaded at all.
I figured as much. gem 'buildr' brings you all the right
requirements, including the very same RSpec you ran Buildr with; it
doesn't load Buildr or any of the dependencies.
$ ruby -rubygems -e "gem 'buildr' ; Buildr"
-e:1: uninitialized constant Buildr (NameError)
$ ruby -rubygems -e "require 'spec' ; p Spec::VERSION::STRING"
"1.1.8"
$ ruby -rubygems -e "gem 'buildr' ; require 'spec' ; p Spec::VERSION::STRING"
"1.1.5"
Assaf
>
>
>> That would require some hack to support the test cases, though.
>>
>>
>
> --
> vic
>
> Quaerendo invenietis.
>
