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 <michael.guy...@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.guy...@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....@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 >>> >>> zin...@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) >>> zin...@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] >>> zin...@imperator:~/devel/src/ruby/mguymon-buildr$ buildr --version >>> Buildr 1.4.3 >>> >>> thanks, >>> Michael >>> >>> >
