Parallel bundle install interferes with post-install hooks

[headius]

Describe the problem as clearly as you can

When running bundle install --jobs with more than one job, dependencies needed for a post-install hook may be in the middle of being installed and not yet functional.

In the case of JRuby, this situation prevents gems with jar-dependencies post-install hooks from successfully fetching necessary jars.

Did you try upgrading rubygems & bundler?

Confirmed on bundler 4.0.8.

Post steps to reproduce the problem

An example run locally, using parallel bundle install to set up local development dependencies for the ruby/stringio gem:

$ rm -rf Gemfile.lock
$ bundle install --force --jobs 3
Fetching https://github.com/ruby/ruby-core-tasks.git
Fetching gem metadata from https://rubygems.org/.......
Resolving dependencies...
Installing rake 13.3.1
Installing erb 6.0.2 (java)
Installing jar-dependencies 0.5.5
Installing date 3.5.1 (java)
Installing power_assert 3.0.1
Installing rake-compiler 1.3.1
Installing tsort 0.2.0
Installing ruby-maven-libs 3.9.9
Installing psych 5.3.1 (java)
  jar dependencies for psych-5.3.1-java.gemspec . . .
Installing test-unit 3.7.7
Installing test-unit-ruby-core 1.0.14
Error: Could not find or load main class org.codehaus.plexus.classworlds.launcher.Launcher
Caused by: java.lang.ClassNotFoundException: org.codehaus.plexus.classworlds.launcher.Launcher

Saving session...
...saving history...truncating history files...
...completed.
--- ERROR REPORT TEMPLATE -------------------------------------------------------

The errors vary from run to run. The ClassNotFoundException above indicates that the command launched for the ruby-maven post-install fetch of snakeyaml could not find a class that should have been included in ruby-maven-libs.

I believe this is caused by the ruby-maven and ruby-maven-libs gems being installed concurrently to the post-install hook. If they are not yet done unpacking, the post-install hook will attempt to use them while they are incomplete, causing random errors.

Specifying no --jobs flag still appears to run in parallel, so I assume it started defaulting to parallel installs at some point.

When run with --jobs 1, it is able to complete successfully every time:

[] stringio $ rm -rf Gemfile.lock            
[] stringio $ bundle install --force --jobs 1
Fetching https://github.com/ruby/ruby-core-tasks.git
Fetching gem metadata from https://rubygems.org/.......
Resolving dependencies...
Installing rake 13.3.1
Installing date 3.5.1 (java)
Installing erb 6.0.2 (java)
Installing jar-dependencies 0.5.5
Installing power_assert 3.0.1
Installing psych 5.3.1 (java)
  jar dependencies for psych-5.3.1-java.gemspec . . .
      org.snakeyaml:snakeyaml-engine:2.10:compile
Installing rake-compiler 1.3.1
Installing tsort 0.2.0
Installing rdoc 7.2.0
Installing ruby-maven-libs 3.9.9
Installing ruby-maven 3.9.3
Installing test-unit 3.7.7
Installing test-unit-ruby-core 1.0.14
Bundle complete! 7 Gemfile dependencies, 15 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
Post-install message from jar-dependencies:

if you want to use the executable lock_jars then install ruby-maven gem before using lock_jars

  $ gem install ruby-maven -v '~> 3.9'

or add it as a development dependency to your Gemfile

   gem 'ruby-maven', '~> 3.9'

Which command did you run?

bundle install with no --jobs flag or with --jobs greater than 1.

The bug does not happen with --jobs 1 to force serial installation.

What were you expecting to happen?

I believe post-install hooks should be deferred until dependencies have been successfully downloaded and fully unpacked, since attempting to run them before this state may result in partial gems being activated for the hook.

If not included with the output of your command, run bundle env and paste the output below

Bundler       4.0.8
  Platforms   ruby, universal-java
Ruby          4.0.0p0 (2026-03-11 revision 991f63ae1a9fd011f49396cd42f740631a67eacd) [universal-java]
  Full Path   /Users/headius/work/jruby/bin/jruby
  Config Dir  /Users/headius/work/jruby/etc
RubyGems      4.0.3
  Gem Home    /Users/headius/work/jruby/lib/ruby/gems/shared
  Gem Path    /Users/headius/.gem/jruby/4.0.0:/Users/headius/work/jruby/lib/ruby/gems/shared
  User Home   /Users/headius
  User Path   /Users/headius/.gem/jruby/4.0.0
  Bin Dir     /Users/headius/work/jruby/bin
Tools         
  Git         2.39.5 (Apple Git-154)
  RVM         not installed
  rbenv       not installed
  chruby      0.3.9
Gem.ruby      /Users/headius/work/jruby/bin/jruby
bundle #!     /usr/bin/env jruby

[headius]

An alternative fix might be to ensure that any gem still being installed cannot be activated, which would prevent the still-being-installed ruby-maven-libs from interfering with the jar-depedencies post-install hook.

[headius]

I still believe there's an issue here but I have figured out that jar-dependencies uses but does not specify ruby-maven as a dependency. As a result, the additional ruby-maven dependency in the stringio Gemfile gets installed in parallel.

I would argue that it should not be possible to activate a gem that is still being installed but by making jar-dependencies explicitly depend upon ruby-maven I work around that issue.

I've pushed a PR to test this change using jar-dependencies 0.5.6.pre1 and it appears to avoid the issue: ruby/stringio#209

[Edouard-chin]

👋 I think the issue you found is the root cause of the problem.

I don't think there is an issue related to plugin hook dispatched too early simply because when installing gems with Bundler, RubyGems plugin are not executed (Bundler only executes gems that contains a Bundler plugin). I see that the jar-dependencies gem includes a RubyGem plugin, not a Bundler plugin

RubyGems plugin only get executed when gems are installed with gem install ...

Specifying no --jobs flag still appears to run in parallel, so I assume it started defaulting to parallel installs at some point.

Yes that's correct ! It uses Etc.nprocessors for the number of jobs by default now (I think it changed a while ago).

Hope this helps !

[headius]

We need to revert the hard dependency on ruby-maven because it's literally only used at install time and includes over 20MB of libraries. This is an ongoing issue.

@Edouard-chin Thank you for the help! I'm still trying to understand what is happening, though, since if what you say is true, all dependencies should be fully installed before the post-install hook runs.

I've pushed a new 0.5.6.pre1 of jar-dependencies to test this, and here's the output I get from a clean install (redownloading, with 3 jobs):

I've included this as a snapshot to show that there's essentially two install processes happening at once.

In green is the top-level install, from running bundle install --redownload --jobs 3. Note that there Installing ruby-maven-libs 3.9.9 in green (that's the direct dependency of stringio) and also Installing 'gem ruby-maven-libs' in white, which is from our post-install hook for the psych gem lazily installing the same gem.

These two installs end up stepping on each other. What I suspect is that the post-install lazy version completes, activates the gem, starts using it, and then the top-level bundle install starts overwriting that already-activated gem. As a result we break the ruby-maven-libs files and get all sorts of weird errors.

So if I'm reading this all right, a shorter summary of the issue might be:

While bundler is parallel installing dependency "foo", a post-install hook also installs and uses "foo". This leads to "foo" being in a bad state and causing errors in the post-install hook, due to the partially-installed library.

The lazy install is needed because we only need ruby-maven-libs at install time to resolve and fetch libraries from Maven, so having it has a hard dependency at runtime is not acceptable.

We are trying to explore other options here but I'd love to chat more about this with folks who understand RubyGems and Bundler well!

[headius]

A bit more confusion for me... it really seems like the jar-dependencies for psych here are being triggered while the rest of the bundling continues. I don't see how they could step on each other if the lazy install of ruby-maven-libs was not happening in parallel with the eager install.