This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Product Version = NetBeans IDE Dev (Build 201003160201) Operating System = Linux version 2.6.32-trunk-686 running on i386 Java; VM; Vendor = 1.6.0_18 Runtime = Java HotSpot(TM) Client VM 16.0-b13 Under Debian based systems, the rubygems is typically deployed using a .deb file; however, this places gems in a non-standard location. When this is updated to the standard gem deployment it resets the main gem environment path to the standard location. When this is done, it appears that the gems reported against the native gem list are not updated in the IDE. This is first presented to the user when creating a new project and the gems are not reported as installed. Steps: (This is based on a clean install on Ubuntu/Debian Linux, but may occur elsewhere) 1) Install Ruby, RubyGems via apt. 2) Install NetBeans and configure the external ruby platform. 3) Create a rails application (to make sure it works) 4) Close NetBeans 5) (From Command Line) sudo gem install rubygems-update 6) /var/lib/gems/1.8/bin/update-rubygems 7) Load the gems required for your environment, include rails 2.3.4 and 2.3.5 8) Delete the old gem folder (/var/lib/gems or /var/lib/gems/1.8) 9) Create a rails project 10) Launch NetBeans 11) Create a new Rails Project for the existing sources -- Make sure you select the native ruby platform When you click finish, you will receive a notice that you do not have rails 2.3.5 installed and that you should remedy the problem. Obviously, if you followed step 7, rails 2.3.5 is installed and the problem is actually a caching issue within the IDE of the gems installed.
Thanks for the report. The wizard should already reload the local gems, but I think GEM_HOME and GEM_PATH are cached (the IDE passes them to the gem tool when running it). In your case one of those env variables changed, right?
As a workaround removing and then re-adding the platform should help. I have to think about how to refresh platform info (GEM_HOME etc) automatically when needed. It is not entirely straightforward as computing the info may take quite long, and also have to consider whether (and how) to preserve any possible user changes in platform config. Maybe an explicit (platform specific) reset action in the platform manager would be enough..
Yes, the GEM_PATH changes when you update the gems in the way I've outlined. I found the unload and re-autodetect the platforms last night. Thank you for confirming this as the way to get around this problem.
Is it possible to do something on a relaunch of the IDE. Something that could "verify" the existance of the paths and configurations within the cache, then report the issues and recommended fixes. Note: This is not a deep dive into the cache to re-verify everything. A path check or test which is rather fast should suffice.
What you propose sounds like a good solution, will implement something along those lines (not sure whether for 6.9 though).
*** Bug 145771 has been marked as a duplicate of this bug. ***