'rails new' putting conditionals in the Gemfile for jruby vs. existing Gemfile template and app_base.rb hacks?

rubyonrails-core
1

Accidentally was in JRuby when I used “rails new …” to generate an app this morning for testing and just realized when I switched back over to MRI ruby and tried to run, do a bundle update, etc. was failing with:

$ rails c Loading jruby-openssl in a non-JRuby interpreter Loading jruby-openssl in a non-JRuby interpreter /path/to/gems/activesupport-3.2.6/lib/active_support/dependencies.rb:251:in require': cannot load such file -- jopenssl (LoadError) from /path/to/gems/activesupport-3.2.6/lib/active_support/dependencies.rb:251:in block in require’ from /path/to/gems/activesupport-3.2.6/lib/active_support/dependencies.rb:236:in `load_dependency’ …

And noticed that, in Rails 3.2.6 + JRuby 1.7.0 at least, it is putting non-conditional stuff in the Gemfile like:

gem ‘activerecord-jdbcsqlite3-adapter’ gem ‘jruby-openssl’

But as documented in various places, conditional includes are suggested: https://github.com/jruby/activerecord-jdbc-adapter

platforms :ruby do gem ‘sqlite3’ end

platforms :jruby do gem ‘jruby-openssl’ gem ‘activerecord-jdbcsqlite3-adapter’ end

In my last job we switched between the two so we put those in manually for a few projects, but was curious that Rails 4/master not introducing Gemfile conditionals for new Rails projects.

I’m assuming it is not conditional just to clean up the Gemfile and to keep people from having to feel like they need to worry about different platforms that they may not care about. But, JRuby usage is common enough now, would it be a good idea to have a single Gemfile?

Also, right now in Rails there are already hacks in the template: railties/lib/rails/generators/rails/app/templates/Gemfile

<%= “gem ‘jruby-openssl’\n” if defined?(JRUBY_VERSION) -%>

and in railties/lib/rails/generators/app_base.rb:

  def convert_database_option_for_jruby
    if defined?(JRUBY_VERSION)
      case options[:database]
      when "oracle"     then options[:database].replace "jdbc"
      when "postgresql" then options[:database].replace "jdbcpostgresql"
      when "mysql"      then options[:database].replace "jdbcmysql"
      when "sqlite3"    then options[:database].replace "jdbcsqlite3"
      end
    end
  end

So, those could be cleaned up and provide the user with more flexibility and insight into what is different between versions by default? Probably another bad idea… Thanks for listening, though.