Needs to be updated to work with bundler 2.0

[mohamedhafez]

Currently, one of the dependencies is bundler ~> 1.5, but bundler 2.0 came out a few months ago.

[Adithya-copart]

I tried changing this dependency locally after cloning this repo. https://github.com/mkristian/jbundler/blob/08f19e1e4574f048b936b8a8536bc414d447330e/jbundler.gemspec#L32

to

s.add_runtime_dependency "bundler", ">= 1.5", '<= 3'

The tests are all green. However, I had to use bundle _2.0.2_ exec jbundle install over jbundle since I'm using jruby 9.2.7.0 that ships with bundler 1.16.6.

$ rake specs
Run options: --seed 26191

# Running:

...............................

Finished in 3.377386s, 9.1787 runs/s, 42.6365 assertions/s.

31 runs, 144 assertions, 0 failures, 0 errors, 0 skips

[jeremyhaile]

Any update here?

[JasonDuckworth]

Is there any update on this? I noticed there has been a change to fix this issue but the latest release (0.9.3) still won't work with bundler 2.0 and above.

[mufti1]

There are failing spec in the CI

[sixtyfive]

$ jruby -S jbundle install
...
You must use Bundler 2 or greater with this lockfile.
$ jruby -S bundler --version
Bundler version 2.2.16

Help, please!

[deivid-rodriguez]

@mkristian I see that you already relaxed the constraint in the default branch to allow bundler 2. Would it be possible to release that? Bundler 2 is used everywhere now.

[jpac-run]

@mkristian Will there be a release with the relaxed constraint?

[mattwelke]

I think I ran into this tonight. I was tinkering with jruby, following this tutorial: https://blog.heroku.com/reactive_ruby_building_real_time_apps_with_jruby_and_ratpack. It's an old tutorial, I know, but I figured there'd still be good concepts to learn.

I tried changing the Gemfile provided in the tutorial to use the version of jruby I had installed right now, which is 9.3.0.0. I ran into an error when I ran the jruby -S bundle install --binstubs command:

Bundler could not find compatible versions for gem "bundler":
  In Gemfile:
    jbundler (= 0.9.2) was resolved to 0.9.2, which depends on
      bundler (~> 1.5)

  Current Bundler version:
    bundler (2.2.14)

I was able to install version 1.17.3 of bundle, like the error output suggested, and run it with bundle _1.17.3_ install, which installed the gems while I was running jruby 9.3.0.0. The command jruby -S bundle _1.17.3_ install --binstubs worked too, so it appears that the jruby command passes the parameters through to any underlying programs that need to be invoked correctly. But it feels like there's some friction here. As a newbie, I'm not sure if I'm setting myself up for issues here.

[mohamedhafez]

@mattwelke or anybody else, my advice would be to just use gradle and specify your maven dependencies in a build.gradle file. Its not a perfect solution, I'm always worried it'll pull in a java class or version of a library that conflicts with or overwrites something that JRuby itself is using, but jbundler is obviously an abandoned project at this point. For what its worth I haven't had any issues though using gradle to pull in Java libraries to my JRuby projects since 2019.

[mattwelke]

@mohamedhafez Thanks for the update. I found the Jarfile and jbundler approach pretty elegant. It was nice to not have to do a full Maven or Gradle setup and still be able to declaratively list JAR dependencies. But I understand open source needs time invested in it. If it's hard to maintain jbundler, I think it's reasonable to ask JRuby users who want to use JAR dependencies to set up Maven or Gradle instead of using jbundler. I imagine only JRuby users with some knowledge of Java would want to use JARs directly anyways, so it's reasonable to assume they'd know about Maven or Gradle.

I think I know of another way JRuby users can get their JAR dependencies. My understanding so far of JRuby is that it's possible to encapsulate JAR files within Ruby gems, in which case bundler takes care of everything without jbundler, Maven, or Gradle being needed. So perhaps an alternative to developers using Maven and Gradle in their Ruby projects would be to create simple gems that are just wrappers around the JAR dependencies. That way, bundler would then install every dependency, including the JAR files.

In fact, I just tested this by adding gem 'rjack-slf4j', '1.7.25.0' to my Gemfile and running bundle. In the output, I see:

...
Use `bundle info [gemname]` to see where a bundled gem is installed.

If I run bundle info rjack-slf4j, the output is:

  * rjack-slf4j (1.7.25.0)
        Summary: A JRuby adaption and gem packaging of the Simple Logging Facade for Java.
        Homepage: http://rjack.gravitext.com/slf4j
        Path: /home/matt/.rbenv/versions/jruby-9.3.1.0/lib/ruby/gems/shared/gems/rjack-slf4j-1.7.25.0-java

If I run tree /home/matt/.rbenv/versions/jruby-9.3.1.0/lib/ruby/gems/shared/gems/rjack-slf4j-1.7.25.0-java, the output is:

/home/matt/.rbenv/versions/jruby-9.3.1.0/lib/ruby/gems/shared/gems/rjack-slf4j-1.7.25.0-java
├── History.rdoc
├── Manifest.txt
├── README.rdoc
├── Rakefile
├── assembly.xml
├── lib
│   ├── rjack-slf4j
│   │   ├── base.rb
│   │   ├── jcl-over-slf4j-1.7.25.jar
│   │   ├── jcl-over-slf4j.rb
│   │   ├── jcl.rb
│   │   ├── jdk14.rb
│   │   ├── jul-to-slf4j-1.7.25.jar
│   │   ├── jul-to-slf4j.rb
│   │   ├── jul.rb
│   │   ├── log4j-over-slf4j-1.7.25.jar
│   │   ├── log4j-over-slf4j.rb
│   │   ├── log4j12.rb
│   │   ├── mdc.rb
│   │   ├── nop.rb
│   │   ├── simple.rb
│   │   ├── slf4j-api-1.7.25.jar
│   │   ├── slf4j-jcl-1.7.25.jar
│   │   ├── slf4j-jdk14-1.7.25.jar
│   │   ├── slf4j-log4j12-1.7.25.jar
│   │   ├── slf4j-nop-1.7.25.jar
│   │   └── slf4j-simple-1.7.25.jar
│   └── rjack-slf4j.rb
├── pom.xml
└── test
    ├── example_jul_to_slf4j.rb
    └── test_slf4j.rb

3 directories, 29 files

So it's clear to me that without having to set up Maven or Gradle, and without even using jbundler, bundler was able to fetch the exact version of the JAR file needed because this gem wrapped the JAR (and its JAR dependencies apparently).

As for the concern of conflicting JAR files being used, as far as I know within the Java ecosystem, shading is used to help with this. Perhaps JRuby's build process could be changed to shade each of its dependencies, guaranteeing that there would be no conflicts with JAR dependencies JRuby users choose to use. That probably deserves a separate discussion though.

[mkristian]

I need to add my input to here:

• yes, I totally agree with @mattwelke on the benefits
• there is jar-dependencies which ships with jruby itself and is almost a dropin replacement for jbundler, see allow warbler to use locked jars from jar-dependencies warbler#481 (comment)
• yes, this project is EOL and was ever since jar-dependencies went into jruby. the only problem was that I never found time to implement allow warbler to use locked jars from jar-dependencies warbler#481
• the only reason you want to use jbundler is its integration with warbler (again allow warbler to use locked jars from jar-dependencies warbler#481) otherwise jar-dependencies works as good or even better.
• jbundler misses a note on EOL and of jar-dependencies at prominent place
• I take all the blame on me

cc/ @headius @deivid-rodriguez

[deivid-rodriguez]

As far as I recall, my one concern was that warbler was actually using this project, and I wanted to get warbler up to date and fix some issues related to bundler.