So someone at my work created a web application in JRuby a while ago, and I'm tasked with...
Understanding the code
Running the JRuby web application locally
Determining whether to fix it up or rewrite it, add functionality, etc.
I'm completely new to JRuby and am kind of struggling with the basics. I'm staring at the code I pulled, containing the folders app, bin, config, lib, script, test, etc. and also containing a Gemfile, Gemfile.lock, a Rakefile, etc. I have no clue how to run this thing locally...
From what I can tell so far, there are a few interacting systems here. They are: JRuby, Ruby, Java, Rails, Gem, Rake, and Bundler. What I am struggling with is how they all work together.
JRuby - My understanding is that, with JRuby, you develop with the Ruby programming language, and it uses the Java Virtual Machine because of whatever benefits therein that I'm unaware of.
Ruby - Ruby has a framework specifically for building web applications, called Rails, which utilizes an MVC framework for ease in creating web applications. JRuby can work off of straight Ruby or Rails.
Rake - I'm not too sure what Rake is. I think it's basically Make. You call rake on a Rakefile and it can perform whatever tasks you specify.
Gem - I think gems are a way of packaging Ruby web applications (rake and bundler are gems?). I'm pretty baffled by this point. I think gem is a command line tool to package a Ruby web application, at which point you refer to it as a "gem."
Bundler - Very lost by this point. I think you define a Gemfile (unsure how Gemfile.lock is used), and use bundler to bundle all of the gems from this Gemfile together. Then you can just include all of these in your app with "require 'bundler/setup'"... although I think you have to require any gems that you defined in your Gemfile again in the app anyways?
JRuby - MRI Ruby (or C Ruby) is the original implementation of the Ruby language. MRI Ruby was written in C. JRuby is the implementation of Ruby on top of the Java Virtual Machine, and a lot of it is written in Java. I'm fuzzy on a lot of the finer details between JRuby and MRI Ruby, but here's what I know based off of what I've learned using JRuby:
JRuby is faster because it's multi-threaded. This means that it can manage multiple requests at once. MRI is not multi-threaded. Therefore, you'll see a lot of benchmarks between JRuby and Ruby, and you'll see that JRuby outperforms Ruby in terms of speed.
JRuby doesn't have as good gem support. This means that you'll be missing out on a lot of gems.
JRuby only recently got Ruby 2.2 compatibility with the release of JRuby 9.0.0.0. However, there's still a lot of kinks to be worked out with the latest version of Rails, so I would do a lot of research into making sure that there aren't major issues between JRuby 9.0.0.0 and Rails 4.2+.
Rake - you've essentially got this correct.
Gem - They're essentially packages of code you can integrate into your projects and run. This is probably the neatest feature of Ruby. Say you want to use the RSpec testing framework. It's super easy to get running if you include that in your project's Gemfile.
Bundler - Gemfiles are exclusive to Bundler. I like to think of Bundler as a dependency manager for your gems. You can specify what versions of each gem will run in your Gemfile, and when you run a bundle install, Bunder will pull and install the specific versions of each of the gems for you. Each bundle install or bundle update will update your Gemfile.lock, which lists out the versions that your project's gems are "locked" to. Gemfiles are exclusive to Bundler, so you'll also see things like .gemspecs floating around in other Rails engines or Rails apps that you may work on.
Related
Given we use a preferred flavour of a ruby version manager (RVM or Rbenv) the ruby gems are isolated per ruby version.
Let's say we want to work on multiple applications locally (they are completely separate applications) and we want to use the same ruby version and the same rails version how do we properly isolate them and their gems? Are gemsets the (only) answer here? I mean if I have 5 applications with the same ruby version and I keep adding gems on all 5 fronts it's just a matter of time when one of the applications is ok with the latest stable gem version while one of the apps will still need to roll on an older version of the same gem due to legacy dependency or whatnot. How do you guys avoid this timebomb?
What if we want to use the same ruby version on multiple apps but a different Rails version? Rails being 'just a gem' is the answer same as for the above?
Thanks.
I'd recommend to use:
rbenv to handle multiple ruby versions on the same machine
bundler to define the dependencies of each application
Make sure to push .ruby_version, Gemfile and Gemfile.lock to make sure every is using the appropriate version of each gem...
What do I need to modify to change my ordinary Ruby on Rails project into a JRuby on Rails project? In addition, is it likely that a gem I included in my RoR project will be broken in the JRuby version of my project?
Lastly is there any way to create a JRuby on Rails app in APTANA or any other editor?
You will need to switch to Jruby instead of Ruby and this could be done using RVM. (www.beginrescueend.com)
You will have problems with gem compatibility when you switch to jruby not all gems will work. Usually gems with C extensions.
Lastly, for an IDE I am sure aptana is fine. You are still writing ruby code. Just when you run your code you will be using the JVM.
The main advantage of jruby instead of normal ruby is we can call the java libraries. And if you want you can even use Hibernate.
And switching if you are on a windows machine you need to use PIK(RVM for windows).
Like ericraio said there may be some gem dependency but most of the time the bundler will take care of that, so you don't need to worry about things(Most of the time).
If you want to check a particular gem please visit this site http://rubygems.org/
For my development I'm using NetBeans 6.9.1. If you want any help regarding how to make you first program in netbeans I'm ready to help.
I prefer to use command prompt to create and run rails project
I have some production Rails 2 apps. I want to start using Rails 3 and Ruby 1.9 for new apps I develop.
I'm using Passenger and Apache with REE (Ruby 1.8.7). I don't vendor anything -- I install gems on the system level and specify versions per app in environment.rb.
If understand it right, the problem is not so much the Rails and other gem versions (because each app can specify their own in environment.rb), but whether my Rails 2 apps and their gems will run under Ruby 1.9.
Do I have that right?
Based on Googling it appears that there may actually be a problem with some gems like Searchlogic and Ruby 1.9.
If so what would be the recommended solution?
I have looked into RVM and it looks fantastic for testing, experimentation, and development. But it doesn't look like it was designed help with a production setup.
As I understand it, when you install Passenger you compile it against one particular version of Ruby. That Ruby can be under RVM no problem, but Passenger can't use different Rubies for different apps.
Look into RVM (Ruby Version Manager). You can manage multiple ruby versions on the same box, and multiple gemsets for each.
http://beginrescueend.com/
Additionally, Bundler allows projects to maintain their own libraries of gems (and for me at least, obviates the need for using RVM gemsets)
http://gembundler.com/
Check the following link for Hongli Lai from Phusion explaining how to set up Passenger running on multiple versions of Ruby simultaneously by using Passenger standalone and reverse proxy.
http://blog.phusion.nl/2010/09/21/phusion-passenger-running-multiple-ruby-versions/
OS X 10.6 has Rails 2.2.2 installed by default.
How to upgrade to Rails 2.3.8?
Since Rails 3 is out, is it possible to have multiple versions of Rails (like 2.3.8 and 3) installed on OS X?
(For example, I could be working on two Rails projects, one is Rails 2.x and the other is Rails 3.x).
Use rvm
RVM is a command line tool which allows us to easily install, manage and work with multiple ruby environments from interpreters to sets of gems...
RVM allows users to deploy each project with its own completely self-contained and dedicated environment--from the specific version of ruby all the way down to the precise set of required gems to run the application. Having a precise set of gems also avoids the issue of version conflicts between projects, causing difficult-to-trace errors and hours of hair loss. With RVM, NO OTHER GEMS than those required are installed. This makes working with multiple complex applications where each has a long list of gem dependencies efficient. RVM allows us to easily test gem upgrades by switching to a new clean set of gems to test with while leaving our original set intact. It is flexible enough to even have a set of gems per environment or development branch--or even individual developer's taste...
I wouldn't bother with gemsets myself just do as other people have mentioned:
gem install -v=2.3.8 rails
and then to use:
rails _2.3.8_ new rails app
Note that this _versionnumber_ thing is a standard way of specifying a version of any rubygems installed executable.
Use
gem install -v=2.3.8 rails
where -v=[version number you want to install]
Then
list gem rails
In your config/environment.rb you can state which version of Rails you want to use.
To upgrade your OS version of the rails gem:
sudo gem install rails --version 2.3.8
While you're at it, you can also upgrade your OS rubygems system itself, overwriting the binary that OS X comes with. This might seem kind of hacky, but it's a stable thing that everyone does.
sudo gem install rubygems-update
sudo update_rubygems
Regarding managing rails versions in your projects, if your only needs are:
Specifying the version of rails that you want on a rails project
Specifying different versions of rails and/or other gems in each of multiple rails projects
Then rvm is overkill. The only thing you need, and what is also a complete and utter pleasure to work with, is Bundler. Bundler is like Software Update for your rails project. In fact, Rails 3 comes with Bundler by default, you just have to list the gems you need in Gemfile and it takes care of the rest. You don't need to worry about which versions of your gems are installed in the OS.
(You do however need the appropriate version of the rails gem installed in the OS in order to generate the rails project in the first place)
http://rubygems.org/
It's all you need =)
I am facing some problem with rails gem when deploying to a differet machine.It requires some extra work on installing gem.Which is most suitable for a rails project.Plugin or Gem.
For Some gems there is no corresponding plugins found.
I am searching for advantages of using plugin over gems and vice versa.
You can unpack gems to your Rails application, which will make sure that they are deployed together with your application:
rake gems:unpack:dependencies
Now you no longer have to install the gems on the server you deploy to. This already takes care of most of the deployment issues. Most others are solved by Bundler, which will be included with Rails 3.
If you can, use gems over plugins. Gems are generally easier to manage, because their versioning is superior to plugins. For public Rails extensions, I see no reason to use plugins instead of gems, but some authors only offer one of the two. In that case you have no choice.
I usually always use a plugin if it is available as it gets frozen into the project, meaning there are no issues when the project is deployed. You can freeze gems into a project but if they require a native build it causes more hassle than it's worth from my experience.
My understanding is gems are easier to upgrade than plugins.
You should also look into the rails 3 bundler which is used to handle these deployment issues.
For me, plugins are preferred. I've run into many a situation where I'll have an improperly configured environment.rb and gems won't have versions assigned to them. Then the server admin does a:
sudo gem update
And now my rspec tests won't run because the update installed test-unit 1.2.2 and my specific setup needs 1.0.1 (or something).