search

mkristian / jbundler

bundler support for jars for jruby
MIT License
210 stars 39 forks source link

Having JRUBY_HOME set to older version of jruby causes jbundle to crash #95

Open christopher-perry opened 4 years ago

christopher-perry commented 4 years ago

This was a giant PITA to track down, but essentially what happens is if you have JRUBY_HOME set (half of our developers did) and your version of jruby is old (ours is 1.7.25), then jbundle install tries to use whatever version of jbundle that points to instead of the jruby-9.2.0.0-jars version, causing it to fail in the following way:

$ jbundle install

...

LoadError: no such file to load -- fileutils
  require at org/jruby/RubyKernel.java:944
    <top> at uri:classloader:/maven/tools/dsl.rb:1
  require at org/jruby/RubyKernel.java:944
    <top> at classpath:/parser.rb:1
[ERROR] Internal error: org.jruby.embed.EvalFailedException: (LoadError) no such file to load -- fileutils -> [Help 1]
org.apache.maven.InternalErrorException: Internal error: org.jruby.embed.EvalFailedException: (LoadError) no such file to load -- fileutils
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:121)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.jruby.embed.EvalFailedException: (LoadError) no such file to load -- fileutils
    at org.jruby.embed.internal.EmbedEvalUnitImpl.run(EmbedEvalUnitImpl.java:131)
    at org.jruby.embed.ScriptingContainer.runUnit(ScriptingContainer.java:1307)
    at org.jruby.embed.ScriptingContainer.runScriptlet(ScriptingContainer.java:1352)
    at org.sonatype.maven.polyglot.ruby.RubyParser.<init>(RubyParser.java:42)
    at org.sonatype.maven.polyglot.ruby.RubyModelReader.read(RubyModelReader.java:56)
    at org.sonatype.maven.polyglot.TeslaModelProcessor.read(TeslaModelProcessor.java:143)
    at org.sonatype.maven.polyglot.TeslaModelProcessor.read(TeslaModelProcessor.java:95)
    at org.apache.maven.model.building.DefaultModelBuilder.readModel(DefaultModelBuilder.java:533)
    at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:273)
    at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:469)
    at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:438)
    at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:401)
    at org.apache.maven.graph.DefaultGraphBuilder.collectProjects(DefaultGraphBuilder.java:419)
    at org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor(DefaultGraphBuilder.java:410)
    at org.apache.maven.graph.DefaultGraphBuilder.build(DefaultGraphBuilder.java:83)
    at org.apache.maven.DefaultMaven.buildGraph(DefaultMaven.java:491)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:219)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
    ... 11 more
Caused by: org.jruby.exceptions.RaiseException: (LoadError) no such file to load -- fileutils
    at org.jruby.RubyKernel.require(org/jruby/RubyKernel.java:944)
    at RUBY.<top>(uri:classloader:/maven/tools/dsl.rb:1)
    at org.jruby.RubyKernel.require(org/jruby/RubyKernel.java:944)
    at RUBY.<top>(classpath:/parser.rb:1)
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/InternalErrorException
Errno::ENOENT: No such file or directory - /home/perryc/workspaces/extension/core3/pkg/dependencies.txt
                  read at org/jruby/RubyIO.java:3804
                  read at org/jruby/RubyIO.java:3987
  install_dependencies at /opt/jruby/lib/ruby/gems/shared/gems/jbundler-0.9.3/lib/jbundler/lock_down.rb:113
             lock_down at /opt/jruby/lib/ruby/gems/shared/gems/jbundler-0.9.3/lib/jbundler/lock_down.rb:54
               install at /opt/jruby/lib/ruby/gems/shared/gems/jbundler-0.9.3/lib/jbundler/cli.rb:80
                   run at /opt/jruby/lib/ruby/gems/shared/gems/bundler-1.12.5/lib/bundler/vendor/thor/lib/thor/command.rb:27
        invoke_command at /opt/jruby/lib/ruby/gems/shared/gems/bundler-1.12.5/lib/bundler/vendor/thor/lib/thor/invocation.rb:126
              dispatch at /opt/jruby/lib/ruby/gems/shared/gems/bundler-1.12.5/lib/bundler/vendor/thor/lib/thor.rb:359
                 start at /opt/jruby/lib/ruby/gems/shared/gems/bundler-1.12.5/lib/bundler/vendor/thor/lib/thor/base.rb:440
                (root) at /opt/jruby/lib/ruby/gems/shared/gems/jbundler-0.9.3/bin/jbundle:47
                  load at org/jruby/RubyKernel.java:1059
                (root) at /opt/jruby/bin/jbundle:23

calling unset JRUBY_HOME and invoking jbundle install again causes it to run as normal.

mkristian commented 4 years ago

Sorry that you ran into this issue. JRUBY_HOME tells any starting jruby process where to find its home which includes the stdlib, preinstalled gems, and other things. mixing basically two jruby. executing jbundle means you execute jruby and tell it to use the other JRUBY_HOME. so things blow up. once started jbundle I can not unset JRUBY_HOME as jruby is already started.

maybe I do miss the point but it makes no sense to set JRUBY_HOME, not for the later jruby-1.7.x versions and not for the 9.x.x.x versions. jruby can find its home and that is what you want to use not some other jruby-home from some other version of jruby. jruby gets tested only with its own jruby-home before release.

hope that helps.