You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@buildr.apache.org by Michael Guymon <mi...@gmail.com> on 2010/11/12 22:25:40 UTC
warbler 1.2 and buildr .1.4.3
Hello,
The spoiler: Warbler wants rubyzip 0.9.4, buildr demands 0.9.1. If
buildr gemspec is updated to >=, a type error pops up due to autoload
:Zip, 'buildr/packaging/zip' in lib/buildr/packaging.rb. What is the
autoload providing? Changing it to a require makes the specs angry, so
there is some magic going into the sauce.
The yarn: So I kicked maven to the curb for buildr on a spring web +
jruby rails project. Oh man, a breath of fresh air. When trying to use
the latest warbler to package the project, I got the following:
RubyGem version error: rubyzip(0.9.4 not = 0.9.1) (Gem::LoadError)
buildr is pinned at rubyzip 0.9.1 and warbler is looking for the latest.
Ok, that is simple enough. I cloned buildr at github and updated the
gemspec to allow rubyzip >= 0.9.1. Unfortunately, that turned up:
TypeError : superclass mismatch for class ZipFile
Hrm, odd. I started poking around buildr a little and figured out the
lib/buildr/packaging.rb is calling autoload :Zip, 'buildr/packaging/zip'
which is causing problems when warbler is requiring rubyzip. So I
blindly changed the autoload to require 'buildr/packaging/zip' and that
fixed that issue, but another error sprung up directly from rubyzip:
NoMethodError : undefined method `length' for -1:Fixnum
/home/zinger/.rvm/gems/jruby-1.5.3@rails3/gems/rubyzip-0.9.4/lib/zip/zip.rb:732:in
`write_c_dir_entry'
Cuuuuurses! Rubyzip's Zip::ZipEntry#write_c_dir_entry has comment = -1
when it expects a string, the angry line of code:
732: @comment ? comment.length : 0,
Somehow, the entry's comment being produced from buildr returns a -1.
Yet again, swinging in the dark, I override the write_c_dir_entry method
in buildr and simply add a to_s method call to comment:
@comment ? comment.to_s.length : 0,
Horray, the project builds! I thought about directly patching rubyzip,
but it is crammed in cvs under sourceforge and I have had enough abuse
for the time being. I added the override to lb/buildr/packaging/zip.rb
My fork of buildr on github - https://github.com/mguymon/buildr
versions
zinger@imperator:~/devel/src/ruby/mguymon-buildr$ java -version
java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
zinger@imperator:~/devel/src/ruby/mguymon-buildr$ jruby -v
jruby 1.1.6 (ruby 1.8.6 patchlevel 114) (2009-06-12 rev 6586) [amd64-java]
zinger@imperator:~/devel/src/ruby/mguymon-buildr$ buildr --version
Buildr 1.4.3
thanks,
Michael
Re: warbler 1.2 and buildr .1.4.3
Posted by Michael Guymon <mi...@gmail.com>.
Thanks for the info, I will put something usable together to submit
On 11/12/2010 05:19 PM, Alex Boisvert wrote:
> It probably goes without saying but ... you may want to comment out our Zip
> patches to see if the specs pass. It's entirely possible that our patches
> are no longer correct on rubyzip 0.9.4. We can rework the sorting
> optimization as a second step (and if still relevant).
>
> On Fri, Nov 12, 2010 at 2:16 PM, Alex Boisvert<al...@gmail.com>wrote:
>
>> We use autoload for all largish gem dependencies so they are loaded lazily
>> and don't affect startup time too much, especially when they are not used in
>> a given buildr execution.
>>
>> We load 'buildr/packaging/zip' because we need to monkeypatch the File
>> class for Ruby 1.9 (see the top of lib/buildr/packaging/zip.rb) and
>> monkeypatch Zip itself to support efficient sorting of entries.
>>
>> alex
>>
>>
>> On Fri, Nov 12, 2010 at 2:02 PM, Michael Guymon<mi...@gmail.com>wrote:
>>
>>> Hey Alex,
>>>
>>> When I changed from autoload to require, it broke 239 specs. I was hoping
>>> someone could tell me why the autoload :Zip, 'buildr/packaging/zip' is used.
>>> Otherwise I need to dig around the specs I broke.
>>>
>>> Once I get the tests working, I will create a new issue with a patch.
>>>
>>> --M
>>>
>>>
>>> On 11/12/2010 04:51 PM, Alex Boisvert wrote:
>>>
>>>> Hi Michael,
>>>>
>>>> Thanks for your sleuthing!
>>>>
>>>> Can you open an issue on https://issues.apache.org/jira/browse/BUILDRand
>>>> attach a patch/diff of your work? (and check the license attachment to
>>>> ASF
>>>> checkbox). This is necesary for us to include your work in buildr.
>>>>
>>>> When that's done I'll include the code and upgrade to rubyzip 0.9.4.
>>>>
>>>> alex
>>>>
>>>>
>>>> On Fri, Nov 12, 2010 at 1:25 PM, Michael Guymon<michael.guymon@gmail.com
>>>>> wrote:
>>>> Hello,
>>>>> The spoiler: Warbler wants rubyzip 0.9.4, buildr demands 0.9.1. If
>>>>> buildr
>>>>> gemspec is updated to>=, a type error pops up due to autoload :Zip,
>>>>> 'buildr/packaging/zip' in lib/buildr/packaging.rb. What is the autoload
>>>>> providing? Changing it to a require makes the specs angry, so there is
>>>>> some
>>>>> magic going into the sauce.
>>>>>
>>>>> The yarn: So I kicked maven to the curb for buildr on a spring web +
>>>>> jruby
>>>>> rails project. Oh man, a breath of fresh air. When trying to use the
>>>>> latest
>>>>> warbler to package the project, I got the following:
>>>>>
>>>>> RubyGem version error: rubyzip(0.9.4 not = 0.9.1) (Gem::LoadError)
>>>>>
>>>>> buildr is pinned at rubyzip 0.9.1 and warbler is looking for the latest.
>>>>> Ok, that is simple enough. I cloned buildr at github and updated the
>>>>> gemspec
>>>>> to allow rubyzip>= 0.9.1. Unfortunately, that turned up:
>>>>>
>>>>> TypeError : superclass mismatch for class ZipFile
>>>>>
>>>>> Hrm, odd. I started poking around buildr a little and figured out the
>>>>> lib/buildr/packaging.rb is calling autoload :Zip, 'buildr/packaging/zip'
>>>>> which is causing problems when warbler is requiring rubyzip. So I
>>>>> blindly
>>>>> changed the autoload to require 'buildr/packaging/zip' and that fixed
>>>>> that
>>>>> issue, but another error sprung up directly from rubyzip:
>>>>>
>>>>> NoMethodError : undefined method `length' for -1:Fixnum
>>>>> /home/zinger/.rvm/gems/jruby-1.5.3@rails3
>>>>> /gems/rubyzip-0.9.4/lib/zip/zip.rb:732:in
>>>>> `write_c_dir_entry'
>>>>>
>>>>> Cuuuuurses! Rubyzip's Zip::ZipEntry#write_c_dir_entry has comment = -1
>>>>> when
>>>>> it expects a string, the angry line of code:
>>>>>
>>>>> 732: @comment ? comment.length : 0,
>>>>>
>>>>> Somehow, the entry's comment being produced from buildr returns a -1.
>>>>> Yet
>>>>> again, swinging in the dark, I override the write_c_dir_entry method in
>>>>> buildr and simply add a to_s method call to comment:
>>>>>
>>>>> @comment ? comment.to_s.length : 0,
>>>>>
>>>>> Horray, the project builds! I thought about directly patching rubyzip,
>>>>> but
>>>>> it is crammed in cvs under sourceforge and I have had enough abuse for
>>>>> the
>>>>> time being. I added the override to lb/buildr/packaging/zip.rb
>>>>>
>>>>> My fork of buildr on github - https://github.com/mguymon/buildr
>>>>>
>>>>> versions
>>>>>
>>>>> zinger@imperator:~/devel/src/ruby/mguymon-buildr$ java -version
>>>>> java version "1.6.0_22"
>>>>> Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
>>>>> Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
>>>>> zinger@imperator:~/devel/src/ruby/mguymon-buildr$ jruby -v
>>>>> jruby 1.1.6 (ruby 1.8.6 patchlevel 114) (2009-06-12 rev 6586)
>>>>> [amd64-java]
>>>>> zinger@imperator:~/devel/src/ruby/mguymon-buildr$ buildr --version
>>>>> Buildr 1.4.3
>>>>>
>>>>> thanks,
>>>>> Michael
>>>>>
>>>>>
Re: warbler 1.2 and buildr .1.4.3
Posted by Michael Guymon <mi...@gmail.com>.
I submitted a patch at https://issues.apache.org/jira/browse/BUILDR-546
that will allow using rubyzip 0.9.4 with buildr
On 11/12/2010 05:19 PM, Alex Boisvert wrote:
> It probably goes without saying but ... you may want to comment out our Zip
> patches to see if the specs pass. It's entirely possible that our patches
> are no longer correct on rubyzip 0.9.4. We can rework the sorting
> optimization as a second step (and if still relevant).
>
> On Fri, Nov 12, 2010 at 2:16 PM, Alex Boisvert<al...@gmail.com>wrote:
>
>> We use autoload for all largish gem dependencies so they are loaded lazily
>> and don't affect startup time too much, especially when they are not used in
>> a given buildr execution.
>>
>> We load 'buildr/packaging/zip' because we need to monkeypatch the File
>> class for Ruby 1.9 (see the top of lib/buildr/packaging/zip.rb) and
>> monkeypatch Zip itself to support efficient sorting of entries.
>>
>> alex
>>
>>
>> On Fri, Nov 12, 2010 at 2:02 PM, Michael Guymon<mi...@gmail.com>wrote:
>>
>>> Hey Alex,
>>>
>>> When I changed from autoload to require, it broke 239 specs. I was hoping
>>> someone could tell me why the autoload :Zip, 'buildr/packaging/zip' is used.
>>> Otherwise I need to dig around the specs I broke.
>>>
>>> Once I get the tests working, I will create a new issue with a patch.
>>>
>>> --M
>>>
>>>
>>> On 11/12/2010 04:51 PM, Alex Boisvert wrote:
>>>
>>>> Hi Michael,
>>>>
>>>> Thanks for your sleuthing!
>>>>
>>>> Can you open an issue on https://issues.apache.org/jira/browse/BUILDRand
>>>> attach a patch/diff of your work? (and check the license attachment to
>>>> ASF
>>>> checkbox). This is necesary for us to include your work in buildr.
>>>>
>>>> When that's done I'll include the code and upgrade to rubyzip 0.9.4.
>>>>
>>>> alex
>>>>
>>>>
>>>> On Fri, Nov 12, 2010 at 1:25 PM, Michael Guymon<michael.guymon@gmail.com
>>>>> wrote:
>>>> Hello,
>>>>> The spoiler: Warbler wants rubyzip 0.9.4, buildr demands 0.9.1. If
>>>>> buildr
>>>>> gemspec is updated to>=, a type error pops up due to autoload :Zip,
>>>>> 'buildr/packaging/zip' in lib/buildr/packaging.rb. What is the autoload
>>>>> providing? Changing it to a require makes the specs angry, so there is
>>>>> some
>>>>> magic going into the sauce.
>>>>>
>>>>> The yarn: So I kicked maven to the curb for buildr on a spring web +
>>>>> jruby
>>>>> rails project. Oh man, a breath of fresh air. When trying to use the
>>>>> latest
>>>>> warbler to package the project, I got the following:
>>>>>
>>>>> RubyGem version error: rubyzip(0.9.4 not = 0.9.1) (Gem::LoadError)
>>>>>
>>>>> buildr is pinned at rubyzip 0.9.1 and warbler is looking for the latest.
>>>>> Ok, that is simple enough. I cloned buildr at github and updated the
>>>>> gemspec
>>>>> to allow rubyzip>= 0.9.1. Unfortunately, that turned up:
>>>>>
>>>>> TypeError : superclass mismatch for class ZipFile
>>>>>
>>>>> Hrm, odd. I started poking around buildr a little and figured out the
>>>>> lib/buildr/packaging.rb is calling autoload :Zip, 'buildr/packaging/zip'
>>>>> which is causing problems when warbler is requiring rubyzip. So I
>>>>> blindly
>>>>> changed the autoload to require 'buildr/packaging/zip' and that fixed
>>>>> that
>>>>> issue, but another error sprung up directly from rubyzip:
>>>>>
>>>>> NoMethodError : undefined method `length' for -1:Fixnum
>>>>> /home/zinger/.rvm/gems/jruby-1.5.3@rails3
>>>>> /gems/rubyzip-0.9.4/lib/zip/zip.rb:732:in
>>>>> `write_c_dir_entry'
>>>>>
>>>>> Cuuuuurses! Rubyzip's Zip::ZipEntry#write_c_dir_entry has comment = -1
>>>>> when
>>>>> it expects a string, the angry line of code:
>>>>>
>>>>> 732: @comment ? comment.length : 0,
>>>>>
>>>>> Somehow, the entry's comment being produced from buildr returns a -1.
>>>>> Yet
>>>>> again, swinging in the dark, I override the write_c_dir_entry method in
>>>>> buildr and simply add a to_s method call to comment:
>>>>>
>>>>> @comment ? comment.to_s.length : 0,
>>>>>
>>>>> Horray, the project builds! I thought about directly patching rubyzip,
>>>>> but
>>>>> it is crammed in cvs under sourceforge and I have had enough abuse for
>>>>> the
>>>>> time being. I added the override to lb/buildr/packaging/zip.rb
>>>>>
>>>>> My fork of buildr on github - https://github.com/mguymon/buildr
>>>>>
>>>>> versions
>>>>>
>>>>> zinger@imperator:~/devel/src/ruby/mguymon-buildr$ java -version
>>>>> java version "1.6.0_22"
>>>>> Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
>>>>> Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
>>>>> zinger@imperator:~/devel/src/ruby/mguymon-buildr$ jruby -v
>>>>> jruby 1.1.6 (ruby 1.8.6 patchlevel 114) (2009-06-12 rev 6586)
>>>>> [amd64-java]
>>>>> zinger@imperator:~/devel/src/ruby/mguymon-buildr$ buildr --version
>>>>> Buildr 1.4.3
>>>>>
>>>>> thanks,
>>>>> Michael
>>>>>
>>>>>
Re: warbler 1.2 and buildr .1.4.3
Posted by Alex Boisvert <al...@gmail.com>.
It probably goes without saying but ... you may want to comment out our Zip
patches to see if the specs pass. It's entirely possible that our patches
are no longer correct on rubyzip 0.9.4. We can rework the sorting
optimization as a second step (and if still relevant).
On Fri, Nov 12, 2010 at 2:16 PM, Alex Boisvert <al...@gmail.com>wrote:
> We use autoload for all largish gem dependencies so they are loaded lazily
> and don't affect startup time too much, especially when they are not used in
> a given buildr execution.
>
> We load 'buildr/packaging/zip' because we need to monkeypatch the File
> class for Ruby 1.9 (see the top of lib/buildr/packaging/zip.rb) and
> monkeypatch Zip itself to support efficient sorting of entries.
>
> alex
>
>
> On Fri, Nov 12, 2010 at 2:02 PM, Michael Guymon <mi...@gmail.com>wrote:
>
>> Hey Alex,
>>
>> When I changed from autoload to require, it broke 239 specs. I was hoping
>> someone could tell me why the autoload :Zip, 'buildr/packaging/zip' is used.
>> Otherwise I need to dig around the specs I broke.
>>
>> Once I get the tests working, I will create a new issue with a patch.
>>
>> --M
>>
>>
>> On 11/12/2010 04:51 PM, Alex Boisvert wrote:
>>
>>> Hi Michael,
>>>
>>> Thanks for your sleuthing!
>>>
>>> Can you open an issue on https://issues.apache.org/jira/browse/BUILDRand
>>> attach a patch/diff of your work? (and check the license attachment to
>>> ASF
>>> checkbox). This is necesary for us to include your work in buildr.
>>>
>>> When that's done I'll include the code and upgrade to rubyzip 0.9.4.
>>>
>>> alex
>>>
>>>
>>> On Fri, Nov 12, 2010 at 1:25 PM, Michael Guymon<michael.guymon@gmail.com
>>> >wrote:
>>>
>>> Hello,
>>>>
>>>> The spoiler: Warbler wants rubyzip 0.9.4, buildr demands 0.9.1. If
>>>> buildr
>>>> gemspec is updated to>=, a type error pops up due to autoload :Zip,
>>>> 'buildr/packaging/zip' in lib/buildr/packaging.rb. What is the autoload
>>>> providing? Changing it to a require makes the specs angry, so there is
>>>> some
>>>> magic going into the sauce.
>>>>
>>>> The yarn: So I kicked maven to the curb for buildr on a spring web +
>>>> jruby
>>>> rails project. Oh man, a breath of fresh air. When trying to use the
>>>> latest
>>>> warbler to package the project, I got the following:
>>>>
>>>> RubyGem version error: rubyzip(0.9.4 not = 0.9.1) (Gem::LoadError)
>>>>
>>>> buildr is pinned at rubyzip 0.9.1 and warbler is looking for the latest.
>>>> Ok, that is simple enough. I cloned buildr at github and updated the
>>>> gemspec
>>>> to allow rubyzip>= 0.9.1. Unfortunately, that turned up:
>>>>
>>>> TypeError : superclass mismatch for class ZipFile
>>>>
>>>> Hrm, odd. I started poking around buildr a little and figured out the
>>>> lib/buildr/packaging.rb is calling autoload :Zip, 'buildr/packaging/zip'
>>>> which is causing problems when warbler is requiring rubyzip. So I
>>>> blindly
>>>> changed the autoload to require 'buildr/packaging/zip' and that fixed
>>>> that
>>>> issue, but another error sprung up directly from rubyzip:
>>>>
>>>> NoMethodError : undefined method `length' for -1:Fixnum
>>>> /home/zinger/.rvm/gems/jruby-1.5.3@rails3
>>>> /gems/rubyzip-0.9.4/lib/zip/zip.rb:732:in
>>>> `write_c_dir_entry'
>>>>
>>>> Cuuuuurses! Rubyzip's Zip::ZipEntry#write_c_dir_entry has comment = -1
>>>> when
>>>> it expects a string, the angry line of code:
>>>>
>>>> 732: @comment ? comment.length : 0,
>>>>
>>>> Somehow, the entry's comment being produced from buildr returns a -1.
>>>> Yet
>>>> again, swinging in the dark, I override the write_c_dir_entry method in
>>>> buildr and simply add a to_s method call to comment:
>>>>
>>>> @comment ? comment.to_s.length : 0,
>>>>
>>>> Horray, the project builds! I thought about directly patching rubyzip,
>>>> but
>>>> it is crammed in cvs under sourceforge and I have had enough abuse for
>>>> the
>>>> time being. I added the override to lb/buildr/packaging/zip.rb
>>>>
>>>> My fork of buildr on github - https://github.com/mguymon/buildr
>>>>
>>>> versions
>>>>
>>>> zinger@imperator:~/devel/src/ruby/mguymon-buildr$ java -version
>>>> java version "1.6.0_22"
>>>> Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
>>>> Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
>>>> zinger@imperator:~/devel/src/ruby/mguymon-buildr$ jruby -v
>>>> jruby 1.1.6 (ruby 1.8.6 patchlevel 114) (2009-06-12 rev 6586)
>>>> [amd64-java]
>>>> zinger@imperator:~/devel/src/ruby/mguymon-buildr$ buildr --version
>>>> Buildr 1.4.3
>>>>
>>>> thanks,
>>>> Michael
>>>>
>>>>
>>
>
Re: warbler 1.2 and buildr .1.4.3
Posted by Alex Boisvert <al...@gmail.com>.
We use autoload for all largish gem dependencies so they are loaded lazily
and don't affect startup time too much, especially when they are not used in
a given buildr execution.
We load 'buildr/packaging/zip' because we need to monkeypatch the File class
for Ruby 1.9 (see the top of lib/buildr/packaging/zip.rb) and monkeypatch
Zip itself to support efficient sorting of entries.
alex
On Fri, Nov 12, 2010 at 2:02 PM, Michael Guymon <mi...@gmail.com>wrote:
> Hey Alex,
>
> When I changed from autoload to require, it broke 239 specs. I was hoping
> someone could tell me why the autoload :Zip, 'buildr/packaging/zip' is used.
> Otherwise I need to dig around the specs I broke.
>
> Once I get the tests working, I will create a new issue with a patch.
>
> --M
>
>
> On 11/12/2010 04:51 PM, Alex Boisvert wrote:
>
>> Hi Michael,
>>
>> Thanks for your sleuthing!
>>
>> Can you open an issue on https://issues.apache.org/jira/browse/BUILDR and
>> attach a patch/diff of your work? (and check the license attachment to ASF
>> checkbox). This is necesary for us to include your work in buildr.
>>
>> When that's done I'll include the code and upgrade to rubyzip 0.9.4.
>>
>> alex
>>
>>
>> On Fri, Nov 12, 2010 at 1:25 PM, Michael Guymon<michael.guymon@gmail.com
>> >wrote:
>>
>> Hello,
>>>
>>> The spoiler: Warbler wants rubyzip 0.9.4, buildr demands 0.9.1. If buildr
>>> gemspec is updated to>=, a type error pops up due to autoload :Zip,
>>> 'buildr/packaging/zip' in lib/buildr/packaging.rb. What is the autoload
>>> providing? Changing it to a require makes the specs angry, so there is
>>> some
>>> magic going into the sauce.
>>>
>>> The yarn: So I kicked maven to the curb for buildr on a spring web +
>>> jruby
>>> rails project. Oh man, a breath of fresh air. When trying to use the
>>> latest
>>> warbler to package the project, I got the following:
>>>
>>> RubyGem version error: rubyzip(0.9.4 not = 0.9.1) (Gem::LoadError)
>>>
>>> buildr is pinned at rubyzip 0.9.1 and warbler is looking for the latest.
>>> Ok, that is simple enough. I cloned buildr at github and updated the
>>> gemspec
>>> to allow rubyzip>= 0.9.1. Unfortunately, that turned up:
>>>
>>> TypeError : superclass mismatch for class ZipFile
>>>
>>> Hrm, odd. I started poking around buildr a little and figured out the
>>> lib/buildr/packaging.rb is calling autoload :Zip, 'buildr/packaging/zip'
>>> which is causing problems when warbler is requiring rubyzip. So I blindly
>>> changed the autoload to require 'buildr/packaging/zip' and that fixed
>>> that
>>> issue, but another error sprung up directly from rubyzip:
>>>
>>> NoMethodError : undefined method `length' for -1:Fixnum
>>> /home/zinger/.rvm/gems/jruby-1.5.3@rails3
>>> /gems/rubyzip-0.9.4/lib/zip/zip.rb:732:in
>>> `write_c_dir_entry'
>>>
>>> Cuuuuurses! Rubyzip's Zip::ZipEntry#write_c_dir_entry has comment = -1
>>> when
>>> it expects a string, the angry line of code:
>>>
>>> 732: @comment ? comment.length : 0,
>>>
>>> Somehow, the entry's comment being produced from buildr returns a -1. Yet
>>> again, swinging in the dark, I override the write_c_dir_entry method in
>>> buildr and simply add a to_s method call to comment:
>>>
>>> @comment ? comment.to_s.length : 0,
>>>
>>> Horray, the project builds! I thought about directly patching rubyzip,
>>> but
>>> it is crammed in cvs under sourceforge and I have had enough abuse for
>>> the
>>> time being. I added the override to lb/buildr/packaging/zip.rb
>>>
>>> My fork of buildr on github - https://github.com/mguymon/buildr
>>>
>>> versions
>>>
>>> zinger@imperator:~/devel/src/ruby/mguymon-buildr$ java -version
>>> java version "1.6.0_22"
>>> Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
>>> Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
>>> zinger@imperator:~/devel/src/ruby/mguymon-buildr$ jruby -v
>>> jruby 1.1.6 (ruby 1.8.6 patchlevel 114) (2009-06-12 rev 6586)
>>> [amd64-java]
>>> zinger@imperator:~/devel/src/ruby/mguymon-buildr$ buildr --version
>>> Buildr 1.4.3
>>>
>>> thanks,
>>> Michael
>>>
>>>
>
Re: warbler 1.2 and buildr .1.4.3
Posted by Michael Guymon <mi...@gmail.com>.
Hey Alex,
When I changed from autoload to require, it broke 239 specs. I was
hoping someone could tell me why the autoload :Zip,
'buildr/packaging/zip' is used. Otherwise I need to dig around the specs
I broke.
Once I get the tests working, I will create a new issue with a patch.
--M
On 11/12/2010 04:51 PM, Alex Boisvert wrote:
> Hi Michael,
>
> Thanks for your sleuthing!
>
> Can you open an issue on https://issues.apache.org/jira/browse/BUILDR and
> attach a patch/diff of your work? (and check the license attachment to ASF
> checkbox). This is necesary for us to include your work in buildr.
>
> When that's done I'll include the code and upgrade to rubyzip 0.9.4.
>
> alex
>
>
> On Fri, Nov 12, 2010 at 1:25 PM, Michael Guymon<mi...@gmail.com>wrote:
>
>> Hello,
>>
>> The spoiler: Warbler wants rubyzip 0.9.4, buildr demands 0.9.1. If buildr
>> gemspec is updated to>=, a type error pops up due to autoload :Zip,
>> 'buildr/packaging/zip' in lib/buildr/packaging.rb. What is the autoload
>> providing? Changing it to a require makes the specs angry, so there is some
>> magic going into the sauce.
>>
>> The yarn: So I kicked maven to the curb for buildr on a spring web + jruby
>> rails project. Oh man, a breath of fresh air. When trying to use the latest
>> warbler to package the project, I got the following:
>>
>> RubyGem version error: rubyzip(0.9.4 not = 0.9.1) (Gem::LoadError)
>>
>> buildr is pinned at rubyzip 0.9.1 and warbler is looking for the latest.
>> Ok, that is simple enough. I cloned buildr at github and updated the gemspec
>> to allow rubyzip>= 0.9.1. Unfortunately, that turned up:
>>
>> TypeError : superclass mismatch for class ZipFile
>>
>> Hrm, odd. I started poking around buildr a little and figured out the
>> lib/buildr/packaging.rb is calling autoload :Zip, 'buildr/packaging/zip'
>> which is causing problems when warbler is requiring rubyzip. So I blindly
>> changed the autoload to require 'buildr/packaging/zip' and that fixed that
>> issue, but another error sprung up directly from rubyzip:
>>
>> NoMethodError : undefined method `length' for -1:Fixnum
>> /home/zinger/.rvm/gems/jruby-1.5.3@rails3/gems/rubyzip-0.9.4/lib/zip/zip.rb:732:in
>> `write_c_dir_entry'
>>
>> Cuuuuurses! Rubyzip's Zip::ZipEntry#write_c_dir_entry has comment = -1 when
>> it expects a string, the angry line of code:
>>
>> 732: @comment ? comment.length : 0,
>>
>> Somehow, the entry's comment being produced from buildr returns a -1. Yet
>> again, swinging in the dark, I override the write_c_dir_entry method in
>> buildr and simply add a to_s method call to comment:
>>
>> @comment ? comment.to_s.length : 0,
>>
>> Horray, the project builds! I thought about directly patching rubyzip, but
>> it is crammed in cvs under sourceforge and I have had enough abuse for the
>> time being. I added the override to lb/buildr/packaging/zip.rb
>>
>> My fork of buildr on github - https://github.com/mguymon/buildr
>>
>> versions
>>
>> zinger@imperator:~/devel/src/ruby/mguymon-buildr$ java -version
>> java version "1.6.0_22"
>> Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
>> Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
>> zinger@imperator:~/devel/src/ruby/mguymon-buildr$ jruby -v
>> jruby 1.1.6 (ruby 1.8.6 patchlevel 114) (2009-06-12 rev 6586) [amd64-java]
>> zinger@imperator:~/devel/src/ruby/mguymon-buildr$ buildr --version
>> Buildr 1.4.3
>>
>> thanks,
>> Michael
>>
Re: warbler 1.2 and buildr .1.4.3
Posted by Alex Boisvert <al...@gmail.com>.
Hi Michael,
Thanks for your sleuthing!
Can you open an issue on https://issues.apache.org/jira/browse/BUILDR and
attach a patch/diff of your work? (and check the license attachment to ASF
checkbox). This is necesary for us to include your work in buildr.
When that's done I'll include the code and upgrade to rubyzip 0.9.4.
alex
On Fri, Nov 12, 2010 at 1:25 PM, Michael Guymon <mi...@gmail.com>wrote:
>
> Hello,
>
> The spoiler: Warbler wants rubyzip 0.9.4, buildr demands 0.9.1. If buildr
> gemspec is updated to >=, a type error pops up due to autoload :Zip,
> 'buildr/packaging/zip' in lib/buildr/packaging.rb. What is the autoload
> providing? Changing it to a require makes the specs angry, so there is some
> magic going into the sauce.
>
> The yarn: So I kicked maven to the curb for buildr on a spring web + jruby
> rails project. Oh man, a breath of fresh air. When trying to use the latest
> warbler to package the project, I got the following:
>
> RubyGem version error: rubyzip(0.9.4 not = 0.9.1) (Gem::LoadError)
>
> buildr is pinned at rubyzip 0.9.1 and warbler is looking for the latest.
> Ok, that is simple enough. I cloned buildr at github and updated the gemspec
> to allow rubyzip >= 0.9.1. Unfortunately, that turned up:
>
> TypeError : superclass mismatch for class ZipFile
>
> Hrm, odd. I started poking around buildr a little and figured out the
> lib/buildr/packaging.rb is calling autoload :Zip, 'buildr/packaging/zip'
> which is causing problems when warbler is requiring rubyzip. So I blindly
> changed the autoload to require 'buildr/packaging/zip' and that fixed that
> issue, but another error sprung up directly from rubyzip:
>
> NoMethodError : undefined method `length' for -1:Fixnum
> /home/zinger/.rvm/gems/jruby-1.5.3@rails3/gems/rubyzip-0.9.4/lib/zip/zip.rb:732:in
> `write_c_dir_entry'
>
> Cuuuuurses! Rubyzip's Zip::ZipEntry#write_c_dir_entry has comment = -1 when
> it expects a string, the angry line of code:
>
> 732: @comment ? comment.length : 0,
>
> Somehow, the entry's comment being produced from buildr returns a -1. Yet
> again, swinging in the dark, I override the write_c_dir_entry method in
> buildr and simply add a to_s method call to comment:
>
> @comment ? comment.to_s.length : 0,
>
> Horray, the project builds! I thought about directly patching rubyzip, but
> it is crammed in cvs under sourceforge and I have had enough abuse for the
> time being. I added the override to lb/buildr/packaging/zip.rb
>
> My fork of buildr on github - https://github.com/mguymon/buildr
>
> versions
>
> zinger@imperator:~/devel/src/ruby/mguymon-buildr$ java -version
> java version "1.6.0_22"
> Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
> Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
> zinger@imperator:~/devel/src/ruby/mguymon-buildr$ jruby -v
> jruby 1.1.6 (ruby 1.8.6 patchlevel 114) (2009-06-12 rev 6586) [amd64-java]
> zinger@imperator:~/devel/src/ruby/mguymon-buildr$ buildr --version
> Buildr 1.4.3
>
> thanks,
> Michael
>