Reputation: 3428
Is there a recommended workaround for warbler not supporting the path options in a Gemfile? Is there a fundamental reason why path is not supported (and I couldn't just implement it)?
Upvotes: 3
Views: 518
Reputation: 6004
I (unfortunately) can't post code for this (yet...), but I have successfully done the following:
Hack warbler (basically replace the whole bundler gem packaging code) to copy gems specified with :path
into vendor/gems
(normal gem location is gems/gems
). This copying was done nearly identically to how warbler copies gems from a :git
specification.
Monkeypatch bundler so when it loads a Gemfile
with :path
specs, they are rewritten to point into vendor/gems
.
It's not pretty, but I have been very happy with this solution.
Another option I have seen is to create a vendor/gems
directory which contains symlinks to all the gems that use :path
in the Gemfile. Warbler will complain about not supporting :path
gems, but they will be copied in the WAR file via the symlinks. I do not like this solution because you've got to maintain the :path
in the Gemfile and the symlink, but it is easier to implement than the above.
Also, I agree with Nick Siger that supporting :path
as-is (without any of the above hacks) does defeat the purpose of a self-contained WAR file, but a self-contained WAR file is not always desirable. There are tradeoffs to a not-self-contained WAR file of course, but one advantage is being smaller in size, quicker to copy, unzip, etc. Of course, supporting this would require changes to JRuby-Rack as well as to Warbler.
Upvotes: 0
Reputation: 3315
The path option is not portable. Bundler expects to be able to find the code at that path, which sort of defeats the purpose of a self-contained war file.
A workaround would be to run "git init; git commit -a" in the directory of the path-based gem and treat it like a git-based gem instead. Then Bundler can check out a copy of the code and Warbler can store the copy in the war file.
Upvotes: 2