If I was in your shoes I would start over by removing JRuby altogether.
All I need on my path to get Java to work is /bin:/usr/bin and I think
the
same is true for your system because you get the same answer to “which
java” as I get.
I have always found JRuby exceptionally easy to use without RVM. (RVM is
essential for MRI Ruby). RVM is installed on my PC but I haven’t used it
for ages. JRuby works fine “in parallel” with it but without using RVM.
I suggest the following steps.
Create a project directory (say myJRtest)
Download the JRuby binary (jruby-bin-1.7.2.zip) save it somewhere safe
and extract it into myJRtest
You will then have a directory structure like this
myJRtest
jruby-1.7.2
bin
docs
etc…
In the directory myRJtest create a shell-script (call it
LocalTerminal.sh) with the following contents which will create the
minimal necessary PATH
#!/bin/bash
x-terminal-emulator -e bash -c "
export PATH=/bin:/usr/bin:$PWD/jruby-1.7.0/bin;
/bin/bash"
Make the shell-script executable.
When you double-click the shell-script it should open a terminal at the
directory myJRtest and you should be able to do java -version jruby -v
and everything else.
Check what’s in your path with echo $PATH - it should only be what is
exported in the shell-script. On my PC I had to temporarily rename
/home/robin/.bashrc so it wasn’t used.
All this should ensure that there is nothing getting in the way of
JRuby. If it works (and I would be surprised if it doesn’t) it should
provide a starting point for further trouble shooting.
I always use this method to run JRuby but my regular PATH command is
export PATH=$PWD/jruby-1.7.0/bin:$PATH;
which retains the other elements of my PATH
…Robin
John -
- In your bash profile just do ‘export JAVA_HOME=
/usr/libexec/java_home
’
This is what I see about that filespec:
[0] 13:09 mac13 /usr/libexec
cd java_home
cd: not a directory: java_home
[1] 13:10 mac13 /usr/libexec
ls -l java_home
lrwxr-xr-x 1 root wheel 79 Nov 14 15:15 java_home ->
/System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java_home
So java_home is apparently a command, and not suitable as a value for
JAVA_HOME.
Also, to get the Java version, it’s “java -version” (see other message).
Regarding the difficulties here, I’d like to offer my opinion that it is
not JRuby but Mac OS that presents the obstacles.
Or, otherwise put, both JRuby and MRI Ruby are much simpler to configure
in Linux than in Mac OS. In Mac OS, I’ve had problems with MRI Ruby and
its native extensions needing a different compiler from the XCode
installation’s. I got that to work, and now brew doctor reports
problems due, I think, to those modifications.
Ironic, isn’t it – Mac OS is supposed to be easier to use. In many
ways it is, but when it comes to development related things like this, I
find Linux much simpler. Maybe that’s unfair because I know Linux
better than Mac OS, I don’t know.
Exactly - it’s a command and that was how I used it in my example. I’m
setting JAVA_HOME to the return value.
12 feb 2013 kl. 19:18 skrev Keith B. [email protected]:
I see, you’re right, sorry.
Not sure why this is, but I actually set everything through .profile
(not .bash_profile). Otoh if you’ve verified that java is reachable on
from the
shell I don’t see why there should be trouble.
Does both “java -v” and “ruby -v” return the values you’d expect?
12 feb 2013 kl. 18:28 skrev Nicole V. [email protected]:
John Axel E. wrote in post #1096513:
Not sure why this is, but I actually set everything through .profile
(not .bash_profile). Otoh if you’ve verified that java is reachable on
from the
shell I don’t see why there should be trouble.
Does both “java -v” and “ruby -v” return the values you’d expect?
12 feb 2013 kl. 18:28 skrev Nicole V. [email protected]:
John,
Yes “java -v” and “ruby -v” return the values you’d expect. I will try
putting in .profile and see what happens…thx.
On Tue, Feb 12, 2013 at 10:22 PM, Keith B.
[email protected] wrote:
Christian -
That may be a good test for the configuration option, but for general use, there
are advantages to using rvm. Mainly that you can use the same commands that you
would use with MRI ruby – rake, gem, rails, ruby, etc…and that you can easily
manage multiple versions of JRuby. Also that all your gems, etc., are in one
place – ~/.rvm.
do use rbenv occasionally. there my gems stay where they are
~/.gem/ruby/1.8, ~/.gem/ruby/1.9 ~/.gem/jruby/1.8, etc so gem itself
has a bulit in feature to separate gems on a per ruby level:
user-install
then using bundler helps avoiding gem version conflicts.
on top of that rbenv is designed to have minimal dependency or impact
on the environment. that is most probably the debian people suggest to
use rbenv and even never mention rvm (which has some issue the way it
integrates with environment). once I wanted to debug a rubygems with
rvm and I just gave up because I did not find anything anymore.
It’s a matter of personal preference, of course, and the way you describe is
fine if you like it that way.
well, mostly I use jruby within a java program, and the launcher is
mainly MRI which starts java (MRI is just so much faster for the
command line). actually the last project I used a simple script to
generate a load_path.rb file with the help of bundler, which I use to
startup my rackup and feels faster the startup (and it is really
faster).
rvm is not the only one there is rbenv or less featured ruby-switch
from debian-testing
bundler is not the only one, there is isolate or maybe others
and as you say it is a matter of preference and there are popular
solutions and unpopular solutions