Tested on Linux, Saves well but is ignored at the end (embedded rails used...)

this works for me (but maybe i don't get the point);

- go to Tools|Options|Ruby installation
- change ruby interpret to e.g. /somefolder/ruby
- change rails to e.g. /somefolder/rails
- push OK
- restart ide
- I go to Tools|Options|Ruby installation -> settings are persistant

NetBeans IDE Dev (Build 200702251900)
1.6.0; Java HotSpot(TM) Client VM 1.6.0-b105
Linux version 2.6.17-10-generic running on i386
cs_CZ (nb); UTF-8 + ruby from update center

musilt2, As I said persistence works in Linux but not in Windows. And anyway
even on Linux it is ignored.

I just tried on Linux, and it worked for me. Here's the process I followed:

Start NetBeans - create a Ruby project.  JRuby is indexed.

Open Tools | Options, modify the Ruby interpreter to "/usr/bin/ruby" (I at first
made a mistake and changed only the path, so I had /usr/bin/jruby - that won't
work). I also modified the rails binary to /usr/bin/rails/.

I closed the dialog and exited the IDE.

I verified that in my userdir, I had the following file:

~/.netbeans/dev/config/Preferences/org/netbeans/modules/ruby/project.properties

It contained:

% cat project.properties
#Tue Feb 27 16:37:42 PST 2007
ruby=/usr/bin/ruby
newApplicationCount=8
rails=/usr/bin/rails

When I started the IDE, it proceeded to index /usr/lib/ruby/1.8 etc.

To double check, after the indexing completed I did

require 'i'

and hit code completion with the caret after the i - I got the match

require 'i486-linux/rbconfig'

I ctrl-clicked on it and it warped into the rbconfig.rb file in my native Ruby
installation under /usr/.


Sauvray, can you try the above steps and see where your behavior is different
from mine?

I actually ran into a bug that I fixed: I recently added behavior that would
also index Ruby code under site_ruby/. If you run the IDE with assertions on
(which might be the case for all dev builds) this will assert if you
installation does not have e.g. /usr/lib/ruby/site_ruby/.  If you run into this
assertion, either create the above directory, or get the latest version - I just
checked in a fix. It should hit the update center within 24 hours.
Alternatively, get a kit from http://deadlock.netbeans.org/hudson/ - those are
updated almost immediately.

Hi Tor,
As I said since beginning, the problem of persistence would appear on Windows
only. In Linux the options are persisted correctly (through the
project.properties) and with today's NB snapshot together with updated Modules,
the indexing takes it into account, so that's great!
    * Common Scripting Language API/Support 0.14.0/0.17.0.1.1.1.1.3
    * Embedded Ruby 0.11.0, JRuby Implementation 0.92.4, Rake-Based Project
Support 0.10.0, Ruby IDE Support 0.20.0, Ruby On Rails 1.1600.0, Ruby on Rails
Project Support 0.16.0, Ruby Projects 0.17.0.1

So at the end I have the original bug that is still present with latest snapshots :
Tools / Options | Miscellaneous / Ruby installation binaries path won't be saved
under Windows.
When I manually edit project.properties to point to my path, things go well! 

Thanks for reproducing this; it's interesting to know that the problem is
related to the actual Preferences API calls. I really don't know why they
wouldn't work on Windows - the code is pretty trivial. I'll have to investigate
next time I'm near a Windows machine. At least there is a temporary workaround
now; I'll add that to the wiki.

Hi Tor,
In fact the persistence on windows will work when you wait a bit before
reopening the option dialog box.
To reproduce :
Open options : PATHA is set for option1, Set PATHB instead and Click OK and
reopen immediately the options, you'll see PATHA is still there (as the cache
didn't take into account your modification), then desperately you click OK again
with PATHA which will remain then...

I had a quick look at the code UpdateHelper... And it seems as if it's a problem
of Synchronization (maybe the NetBeans ProjectManager Mutex or the way it is
used or the way you cache configuration).
It can be reproduced with any of the items from the Tools / Options |
Miscellaneous, so the bug could be fixed by another transversal api team and not
you except if it's a bad way way you're all using the api or caching ;)

I would note that much the same is happening on OS X.  I specified a different
jruby installation, and it saved the correct values to
~/.netbeans/dev/config/Preferences/org/netbeans/modules/ruby/project.properties

~/.netbeans/dev/config/Preferences/org/netbeans/modules/ruby $ more
project.properties 
#Sun Mar 11 07:48:26 CDT 2007
ruby=/Users/epowell/Development/jrubydev/jruby/bin/jruby
rails=/Users/epowell/Development/jrubydev/jruby/bin/rails
rdoc=/Users/epowell/Development/jrubydev/jruby/bin/rdoc
rake=/Users/epowell/Development/jrubydev/jruby/bin/rake


However, when I start up an irb session, it shows the Netbeans-default jruby paths:

irb(main):001:0> $LOAD_PATH
=> ["/Users/epowell/.netbeans/dev/jruby-0.9.2/lib/ruby/site_ruby/1.8",
"/Users/epowell/.netbeans/dev/jruby-0.9.2/lib/ruby/site_ruby",
"/Users/epowell/.netbeans/dev/jruby-0.9.2/lib/ruby/1.8",
"/Users/epowell/.netbeans/dev/jruby-0.9.2/lib/ruby/1.8/java", "lib/ruby/1.8", "."]

The IRB console behaving this way is a slightly different issue.  The IRB console is hardcoded to JRuby at 
the moment because it allowed nice readline integration (completion handling, command history, etc.). 
Launching external processes (which would be required for running other installations) wouldn't allow 
us to do this - the output window doesn't have integrated I/O etc - there's a separate text field for 
input (although this is hopefully going to be fixed for milestone 9 by issue #84375).

With the rails console etc. I realize I'm going to have to change this soon.

Regarding persistence/setting of ruby installations: I've just fixed various issues relating to running 
native ruby (including other versions than 1.8) so it should mostly work now.

I'm not sure what's wrong with the persistence code here, but I'm going to replace it completely with a 
proper paltform chooser (ala the Java Platform manager).

Reassigning this issue to newly created 'ruby' component.

I have access to Windows now and I tried to reproduce it - but it worked for me. Is still a problem on your system? (The bug is nearly six months old now and 
a LOT has changed in the code so I'm hoping this is fixed.)

Hi tor,
Indeed, it's fixed since some month already.
Sébastien.