Fixes to update Warbler to modern libs and JRuby
This PR will encompass fixes to get Warbler updated for modern JRuby, modern Ruby, and modern versions of necessary libraries.
Fixes here will try to resolve #558.
I removed a hack by @nicksieger that apparently worked around some issues with gem specifications' "loaded from" attribute when loading bundler. The logic presented does not properly handle the case where the running bundler is a default gem (as it is in any recent release of JRuby) and I'm not sure if it's necessary anymore in any case.
jbundler-related failures are going to need an update to that library. I've started the process here: https://github.com/mkristian/jbundler/pull/104
cc @mkristian I need to move that repo over to jruby org and get push rights with you get a chance. Thank you!
maven-tools 1.2.3 has been released which included a few unreleased fixes. This eliminates some build failures due to it referencing the defunct torquebox gem proxy URL.
With an updated jbundler (only available as a local build) and maven-tools I have failures down to four:
1) Warbler::Jar with Bundler in a war project with :git entries in the Gemfile works with :git entries in Gemfiles
Failure/Error: ruby "-I#{Warbler::WARBLER_HOME}/lib", File.join(@orig_dir, 'spec/drb_helper.rb')
Errno::EINTR:
Interrupted system call - Another thread waited the process started by system().
# ./spec/spec_helper.rb:132:in 'block in run_out_of_process_with_drb'
2) Warbler::Jar with Bundler when frozen with the runnable feature can run commands in the generated warfile
Failure/Error: expect(stderr.readlines.join).to eq("")
expected: ""
got: "/private/var/folders/h_/tmq357111c18sxbwlyq34mh80000gn/T/jruby11766745306540500674extract/gems/gems/...tarting from Ruby 3.5.0.\nYou can add ostruct to your Gemfile or gemspec to silence this warning.\n"
(compared using ==)
Diff:
@@ -0,0 +1,2 @@
+/private/var/folders/h_/tmq357111c18sxbwlyq34mh80000gn/T/jruby11766745306540500674extract/gems/gems/rake-12.3.3/exe/rake:27: warning: ostruct was loaded from the standard library, but will no longer be part of the default gems starting from Ruby 3.5.0.
+You can add ostruct to your Gemfile or gemspec to silence this warning.
# ./spec/warbler/bundler_spec.rb:226:in 'block in <main>'
3) Warbler::Jar with Bundler when deployment includes the bundler gem
Failure/Error: expect(file_list(%r{gems/bundler-.*/lib})).to_not be_empty
expected `[].empty?` to be falsey, got true
# ./spec/warbler/bundler_spec.rb:240:in 'block in <main>'
4) Warbler::Task should allow bytecode version in config
Failure/Error: expect(class_file_bytes[6..7]).to eq bytecode_version.map { |magic_char| magic_char.chr }.join
expected: #<Encoding:US-ASCII> "\x004"
got: #<Encoding:ASCII-8BIT> "\x00A"
(compared using ==)
# ./spec/warbler/task_spec.rb:137:in 'block in <main>'
# ./lib/warbler/zip_support.rb:10:in 'open'
# ./spec/warbler/task_spec.rb:133:in 'block in <main>'
The first failure seems to be an issue with the subprocess launch of drb, perhaps using some old pattern for launching processes
The second failure is due to ostruct being a stdlib gem starting in Ruby 3.5 and warning right now. Adding to Gemfile should fix this.
The third failure and fourth failure need investigation.
I've dealt with the ostruct issue by adding it as a dependency and using a newer version of rake that doesn't also use it blindly.
The bytecode version failure was due to JRuby 10 always using bytecode versions higher than 21, since that's the minimum version it supports. I patched the test to handle that situation. I also modified the way this code tries to specify a specific bytecode version; tweaking java.specification.version directly seems pretty icky and isn't needed now in any case.
This is using jbundler 0.9.5 which is unreleased, so it will just fail hard until that's pushed.
Thanks for this work and for the excellent updates along the way. Easy to learn from, super helpful.
The DRbServer used for running some tests remains a little flaky, but with latest changes this should be green on JRuby 10.
jbundler 0.9.5 has been released and that project moved to JRuby org control so CI should also be green (or soon).
@headius Perhaps a step "just run 1 version of Bundler" could simplify the look of the CI matrix just a little. That is: deleting "2.6.3" from the string "21, jruby-head, 2.6.3".
@olleolleolle Yeah good idea. No really compelling reason to test against several versions anymore.
I ran into issues by using current master to warble a Rails app and also a minimal Sinatra app (with a local snapshot build from jruby-rack 1.3.0) and deploy it to a Tomcat.
@headius: I also noticed that CI seems to be green, but failed because bundle exec rake integration always returns a successful return code. Have you noticed that? https://github.com/jruby/warbler/actions/runs/15866068938/job/44733092626#step:7:1212
@mjansing Yeah I realize there's still some work needed here. I'll be circling back to this once we have JRuby 10.0.1.0 out.
I also see that some of the integration tests are not really passing, so that will get fixed too. We're getting there! If you see small things you can fix, please submit a PR.
@headius Thanks a lot for your changes! @mjansing and I gave them a try, which led to one issue we couldn't resolve (#561) and two follow-up PRs (#564, #562).
Since #561 makes it difficult to test Warbler directly from a Git dependency (you need to build and install the gem manually without using bundler), we published a temporary gem to simplify testing.
Details are in this comment.
Slightly unrelated to this and #554, but as you've probably seen I have been doing some work on jruby-rack to try and get things working with newer rails versions etc, resurrect all the testing etc - although still big gaps with the Rails regression testing to resolve. Warbler is a blind spot for me since the jruby-rack app I maintain (GoCD) uses embedded Jetty and assembles its war files manually itself rather than using warbler.
However, if I can help with digging into anything caused by jruby-rack problems or needing jruby-rack support, feel free to ping me and I'll see what I can do.
Given the adjacency of the tools, some of the CI challenges here are possibly ones I've had to address earlier for jruby-rack or have some kind of approach to workaround.