In my rather unique application needs, I've had to make a patch to JRuby-1.7.26. However, I've learned that Warbler (that uses jruby-jars) embeds it's own copy of JRuby into my lib/ directory. How can I configure either Warbler or jruby-jars to consider my patch when it compiles JRuby?
you need to build a custom version of jruby-jars gem (from the JRuby source)
and then specify that version to be used in the Gemfile :
gem 'jruby-jars', '1.7.26.PATCH', require: false
Related
The current Trinidad gem depends on jruby-rack 1.1.0 which has some errors being displayed in my development log for every single one of my assets
/Users/bijan/.rvm/gems/jruby-1.7.3/gems/rack-1.4.5/lib/rack/utils.rb:399 warning: multiple values for a block parameter (2 for 1)
This is an issue that has apparently been resolved in the current jruby-rack (1.2) master branch and I'd like to make trinidad depend on this.
Is there a way to do this from within my Gemfile? Or another simpler solution than forking the Trinidad gem and specifying a different version of jruby-rack (and wishing it works since it may not).
TL;DR - not really. You'll need to build one or both projects or get some help from the jruby-rack team by way of a release. See bottom for build steps.
The current Trinidad versions (1.4.4 and 1.4.5B1 prerelease) use jruby-rack with optimistic versioning (>= 1.1.10 and >= 1.1.13, respectively), so any dependency that satisfies this (say, 1.2.0) would take precedence without touching Trinidad.
Unfortunately, because of how the JAR is packaged, a git: or github: dependency will not work. You would need to build the gem yourself. This is not too bad -- you really just need Maven beyond a working JDK/JRuby setup.
Once jruby-rack is built/released with the changes, will be able to specify a workable version in your Gemfile (assuming it gets versioned 1.2.0):
gem 'jruby-rack', '~> 1.2.0'
gem 'trinidad'
Maybe the jruby-rack team could backport this specific change to the 1.1.13 maintenance line and push a 1.1.13.2 release if it doesn't introduce incompatibility. Or they may be willing to do a prerelease from master.
I haven't tested that things work properly for assets, but building and specifying the local version was relatively easy:
# Assuming mvn is on the path, JRuby is active, and you
# have gem install permissions:
git clone https://github.com/jruby/jruby-rack.git
cd jruby-rack
bundle install
bundle exec rake clean gem SKIP_SPECS=true
gem install --local target/jruby-rack-1.2.0.SNAPSHOT.gem
After this, you can use gem 'jruby-rack', '~> 1.2.0.SNAPSHOT' in your Gemfile to satisfy Trinidad and test whether your problem is resolved.
I'm using capistrano to deploy a rails app, and it uses bundle install --deployment to put the gems in shared/bundle. I've put the appropriate platform :ruby and platform :jruby blocks in my gemfile, my question is if I switch rvm to jruby and then go to my app root directory and do another bundle install --deployment, will that mess with any of the existing gems there and replace them with jruby ones? Will I be able to switch back to mri and run the app like I always have? Will both platform's gems be in there, and then what about gems like nokogiri that have java versions, will that overwrite the mri version? Will I be able to just switch rvm versions and run the app via mri or jruby as I please at that point?
Turns out mri gems are installed in shared/bundle/ruby and jruby gems in /shared/bundle/jruby, so totally safe to switch to jruby, install your gems, and try it out
I installed JRuby with rbenv
ruby -v
jruby 1.6.7.2 (ruby-1.9.2-p312) (2012-05-01 26e08ba) (Java HotSpot(TM) 64-Bit Server VM 1.7.0_01) [linux-amd64-java]
which ruby
~/.rbenv/shims/ruby
gem env
RubyGems Environment:
- RUBYGEMS VERSION: 1.8.24
- RUBY VERSION: 1.9.2 (2012-05-01 patchlevel 312) [java]
- INSTALLATION DIRECTORY: /home/myjava_api/.rbenv/versions/jruby-1.6.7.2/lib/ruby/gems/1.8
- RUBY EXECUTABLE: /home/myjava_api/.rbenv/versions/jruby-1.6.7.2/bin/jruby
- EXECUTABLE DIRECTORY: /home/myjava_api/.rbenv/versions/jruby-1.6.7.2/bin
- RUBYGEMS PLATFORMS:
- ruby
- universal-java-1.7
- GEM PATHS:
- /home/myjava_api/.rbenv/versions/jruby-1.6.7.2/lib/ruby/gems/1.8
- /home/myjava_api/.gem/jruby/1.9
- GEM CONFIGURATION:
- :update_sources => true
- :verbose => true
- :benchmark => false
- :backtrace => false
- :bulk_threshold => 1000
- "install" => "--no-rdoc --no-ri"
- "update" => "--no-rdoc --no-ri"
- REMOTE SOURCES:
- http://rubygems.org/
But $JRUBY_HOME is not set
When I set $JRUBY_HOME to "/home/myjava_api/.rbenv/versions/jruby-1.6.7.2/bin/jruby" and after re-login when I executed "ruby -v" I got error: "Error: Could not find or load main class org.jruby.Main"
When I remove $JRUBY_HOME variable "ruby -v" works fine
What must be correct $JRUBY_HOME value?
I was trying out this tool (rbenv) after managing my PATH by hand for a while, for the first time and got this same error: Error: Could not find or load main class org.jruby.Main
I had completely forgotten to unset the old JRUBY_HOME setting in my .bash_rc file, after uninstalling my previous version of jruby to try out rbenv.
In response to the other answers, I have certain tools and libraries that require the JRUBY_HOME variable to be set in order to work, http://vertx.io/ is one example. On the other hand, a number of gems and tools these days go the other route, and seem to assume that you are using either rvm or rbenv. So using one of those tools, but continuing to set JRUBY_HOME seems to be the path of least resistance.
Fortunately, when JRUBY_HOME is set correctly, it will work just fine with rbenv. For instance, mine is set like this export JRUBY_HOME="/home/user/.rbenv/versions/jruby-1.7.1"
The original poster's error appears to be trying to set the variable to the jruby executable, when in fact JRUBY_HOME should simply be the entire jruby directory. I think his should be "/home/myjava_api/.rbenv/versions/jruby-1.6.7.2". Hope that clears things up. I realize this is an old question, but when I searched the error, it was the first relevant result.
The whole point of utilities like rbenv or rvm is to be able to switch between ruby implementations without worrying about changing environment variables, as they do it for you; you shouldn’t need to set $JRUBY_HOMEto run JRuby (which incidentally for you would be /home/myjava_api/.rbenv/versions/jruby-1.6.7.2) as these utilities are aimed to make the underlying implementation transparent.
I guess the obvious question is why do you want $RUBY_HOME if it works fine without it?
JRuby is so simple to install you don't need any version manager. Just download the Zip file and extract it to any directory you like. Then add the JRuby/bin directory to your path. In your case that would seem to be /home/myjava_api/.rbenv/versions/jruby-1.6.7.2/bin.
If you have several projects that require different versions of JRuby or different groups of gems just extract a copy of the appropriate JRuby version for each project. Assuming you use the correct PATH for each project the correct version of JRuby will run and it will have all the gems you installed for that project, and each project will be quite separate.
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)?
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.
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.
I built my Rails 3 app using sqlite and now I'm trying to switch over to MySQL.
I created a new MySQL db, changed database.yml accordingly, and I added an older version of the mysql2 gem to my gemfile (gem 'mysql2', '< 0.3') which is supposed to play nicer with Rails 3.
I can start the dev server fine. When I visit a page, I get a Mysql2::Error (Table 'twitter_quiz_development.users' doesn't exist). Which is fine--I still need to add the schema to the new db. This is where I run into trouble:
rake db:schema:load returns this nasty error.
The solution found here did not work for me. gem pristine --all return this.
I'm running Ubuntu 11 if that helps.
It appears that the error has to do with JSON but I have no idea how to solve this. Thanks.
The issue(s) you are experiencing could be due to 3 things:
The version of Ruby you are using
The use of the SystemTimer gem with Ruby 1.9
The JSON gem
I've elaborated below...
The first thing I would suggest is to upgrade your version of Ruby 1.9. The latest stable is:
ruby 1.9.2p180 (2011-02-18 revision 30909)
I would highly recommend using Ruby Version Manager (RVM) to install and manage Rubies.
In terms of using the JSON gem, have a look at:
http://ruby.about.com/od/tasks/a/The-Json-Gem.htm
To quote:
On Ruby 1.8.7, you'll need to install a gem. However, in Ruby 1.9.2, the json gem is bundled with the core Ruby distribution. So, if you're using 1.9.2, you're probably all set. If you're on 1.8.7, you'll need to install a gem.
Before you install the JSON gem, first realize that this gem is distrubuted in two variants. Simply installing this gem with gem install json will install the C extension variant. This requires a C compiler to install, and may not be available or appropriate on all systems. Though if you can install this version, you should.
If you can't install the C extension version, you should gem install json_pure instead. This is the same gem implemented in pure Ruby. It should run everywhere that Ruby code runs, on all platforms and on a variety of interpreters. However, it's considerably slower than the C extension version.
Edit:
Looks like you should avoid using the SystemTimer gem with Ruby 1.9. See this for more info: http://isitruby19.com/systemtimer
To quote a comment made on that page by Phillipe:
I am the (co)-author of this gem. Short story : Using this gem in Ruby 1.9 is useless and does not make any sense!
System Timer is trying to work around some limitation of the "green thread" model used in Ruby 1.8 (MRI). See http://ph7spot.com/musings/system-timer for more details.
It is then irrelevant in a Ruby 1.9 which abandoned the green thread model and embraced native threads (kind of since there is still a global interpreter lock).
Cheers,
- Philippe
Your gem pristine --all looks like it errored out with the SystemTimer gem before it got to the json gem. Is that gem used in the Rails app in question?
Are you using RVM? If so, I'd manually remove the SystemTimer and json gems and their binaries (if any) from ~/.rvm/gems/ruby-whatever-version/ (in the gem and bin subdirectories).
Try to update to the latest version of the JSON gem (1.5.1) by adding this to your Gemfile:
gem "json", "1.5.1"
And then run bundle install to install SystemTimer and the later version of the json gem.