So are you proposing that the jruby-complete.jar should ignore JRUBY_HOME? And it sounds like that was the case in 1.7.19 and earlier?

Yes, exactly.

I use JRUBY-COMPLETE as the base for a standalone application jar, which should run on any computer with the right operating system.

Users should not have to worry about the environment it runs in. In a sense the ‘complete’ part of the name says it all. In cases where JRUBY_HOME is needed, it is probably better to use JRUBY.

But maybe others have different use cases in favor of the use of JRUBY_HOME in JRUBY-COMPLETE

I have one idea how to do this...if we set a different main for the complete jar versus the jruby.jar we put into a distribution, we'd know how it was launched. They'd essentially do the same thing, but when running from jar main it wouldn't look at environment variables...only properties.

The other option would be to never look at environment vars in the Java code, and rely on the launchers to do it. Most people who use the env vars use our bin/jruby.bash or the native equivalent, which could just take those environment variables and put them in the right properties.

I do not really understand the issue with jruby-jars.gem (probably because I never used it), but I would favor a solution where the default for jruby-complete is to ignore JRUBY_HOME. The solution as proposed by headius - to set a different main for the complete jar - seems a good way to achieve this.
Apropos of other actions depending on whether running from the "filesystem" or running from a "jar", it would be nice to have a more elegant way to determine this than by inspecting if __FILE__ starts with uri:classloader or contains .jar! as I do at the moment. Maybe it exists and I missed it.
==Cees

I am on it now. but the different main is tricky since the we have several distributions:

• tar.gz or zip binary distribution
• modular maven artifact
• complete/shaded maven artifact for easy command line execution and it is also an OSGi bundle
• jruby-jars gem which is kind of a mix for all the above three

the last three use the same jars from a java point of view. they are only differently packed. one jar or two jars or many jars.

and there is already a way to determine whether we run from classpath which contains META-INF/jruby.home or so that spawing a new jruby process works. here switching the main method would need to follow as well.

so what I am about to do is give preference to META-INF/jruby.home instead of using the environment JRUBY_HOME.

the other issue is not clear to me: the best would be to look at JRuby.runtime.instance_config.jruby_home
to see if the stdlib is on classpath or from filesystem.

or if you code runs from within a jar you can look at Dir.pwd and check if this startsWith uri:classloader: which can be useful for example setting up a log file somewhere outside the application "directory"

probably a check on a given file would help as well. let's see.

@headius that the ScriptingContainer behaves differently, i.e. gives first preference to JRUBY_HOME is something which we do in jruby-1.7.x but I would go for a more uniform solution and remove those code lines: https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/embed/ScriptingContainer.java#L268