The bundle JRuby is a hacked/patched version of JRuby. The right way is to create a standard Library wrapper module for
jruby.jar you downloaded from the official JRuby site and use that. Reassigning to Tor for confirmation.

I would also be nice to bundle 'jruby/build/jruby-engine.jar' out of 'jsr223-engines.tar.gz' to complete the module
for a NB module developer who wants to use it as a scripting engine in a custom module. 

The org jruby jar which sits in the ruby1 cluster is not a generic packaging of the JRuby distro; it's a version of
JRuby that has been patched to make it suitable for IDE use. (The diffs applied to it are in CVS - see
ruby/jruby/jruby.diff). For example, it makes the lexer, which usually is only suitable for parsing (because it throws
away comments, whitespace and documentation sections) also suitable for syntax highlighting such that it returns
whitespace and comment tokens, etc.

For that reason, I can't just take the official ruby bits and wrap them in a library module. We may well need that as
well - but that's a different module than this one, which is really an implementation module for the Ruby support.

Now to the bug at hand: In RC1, we updated JRuby from 1.0.1 to 1.0.2. One of the changes in 1.0.2 was to move the
builtin/java stuff around such that it's now over in lib/ruby/site_ruby/. 

That hasn't showed up as a problem for me - I run this "hacked" JRuby in the IRB window for example. In order for that
work (for it to find not only site_ruby but all the Ruby libraries as well) I also call

RubyInstallation.getInstance().setJRubyLoadPaths();

This really just calls
System.setProperty("jruby.home", jh); // NOI18N

where jh points to the jruby-1.0.2 directory in the cluster. This is used to set up load paths by JRuby etc. such that
it finds all of its supporting "stuff".

Not a stopper for 6.0, setting target milestone to Dev.

Based on Tor's comments I believe this is resolved. Changing status to RESOLVED/WORKSFORME. Please reopen if you don't
find the justification given by Tor satisfactory.

Actually the problem is worse (at least now) and cannot be workarounded. I've tried to play with JSR 223 and when having
o.jruby installed I'm not able to get JSR engine with 'ruby' work. The solution is to wrap own (official) jruby.jar and
*uninstall* o.jruby, which means effectively whole Ruby support.
So one cannot now script NetBeans Ruby IDE with Ruby which is pretty odd. Erno did you succeed with this. I know you
also talked about this. If not...
Tor do you know what could be wrong or did you succeed with some simple JSR 223 sample?

Yeah I got it working after some tinkering.  I used the JRuby distribution we bundle rather than the "internal" patched 
JRuby. What's the problem you're facing, the same as the OP?

I'm just trying something else - probably right think. So one needs likely to bundle JRuby engine from JSR 223 package
and make it dependent on org.jruby? Trying...... will let you know soon.

Even that does not work. Facing:

library `java' could not be loaded: org.jruby.exceptions.RaiseException: no such file to load -- builtin/javasupport

then. I'm just trying to install agent which calls this method:

  private static void listEngines() {
    ScriptEngineManager manager = new ScriptEngineManager();
    ScriptEngine engine = manager.getEngineByName("jruby");
    System.out.println("engine: " + engine);

    ScriptEngineManager seManager = new ScriptEngineManager();
    List<ScriptEngineFactory> factories = seManager.getEngineFactories();
    for (ScriptEngineFactory factory : factories) {
      System.out.println("Languages from : " + factory);
      System.out.println("  " + factory.getLanguageName());
      System.out.println("  " + factory.getLanguageVersion());
      System.out.println("  engine names:");
      for (String name : factory.getNames()) {
        System.out.println("    \"" + name + "\"");
      }
      System.out.println("  mimetypes");
      for (String mimeType : factory.getMimeTypes()) {
        System.out.println("    \"" + mimeType + "\"");
      }
      System.out.println("  script engine: " + factory.getScriptEngine());
    }
  }

(http://java.sun.com/javase/6/docs/jdk/api/attach/spec/com/sun/tools/attach/package-summary.html)

It is enough to call the listEngines method in my previous comment from anywhere in the running IDE. Try to e.g. hook it
no some button in the IDE. No Agent needed at all.

This should be fixed now. As of changeset 3c3456dd9436 I've repackaged the bundled JRuby parser (and the Rhino
JavaScript parser) into its own namespace (org.jruby.nb) such that it should no longer interfere with any org.jruby
scripting engine you have installed.

Can you please try a new build and let me know whether you have any problems. (I tried to verify myself, but the
scripting engine support on my JDK6 on OSX doesn't seem configured correctly - I get errors on all scripting engines -
such as Jython etc. - unrelated to the Rhino and JRuby engines that should have been fixed by my integration.)

Integrated into 'main-golden', available in build *200808230201* on http://bits.netbeans.org/dev/nightly/
Changeset: http://hg.netbeans.org/main/rev/3c3456dd9436
User: Tor Norbye <tor@netbeans.org>
Log: Repackage the modified Ruby and JavaScript parsers in the IDE from their
original package names to packagename+".nb". This is done to avoid
unintentional interactions with the standard versions of these parsers.
For example, attempts to use scripting engines (such as JRuby) has
reportedly had problems (P2 #121952 for Ruby, and some reports about
Mozilla Rhino as well. Another possible bug this fixes is
144637, or at least exception 91820 submitted as a duplicate of that bug.)

The repackaging is done as token replacements as the JRuby and Rhino
parser source zip files are extracted. It turns out JRuby had split
two of its packages into separate jars: the bytelist library, and
JNA-posix. These are left in the original package, and I extracted the
bytelist and jvyamlb libraries into proper NetBeans libraries (libs.bytelist
and libs.jvyamlb). This will help the upcoming task of removing the
dependency of the YAML editor on the JRuby distribution. YAML is used
with Python as well (and in particular in the Google App Engine) so
we should be able to distribute it with the Python distro without JRuby.