Consider moving jar to Maven or eliminating entirely

[headius]

We currently build lib/warbler_jar.jar as part of this gem, even though most of it is not necessary for the execution of the gem.

Two classes in this jar are used by warbler as a JRuby extension to build the resulting archive: WarblerJar and WarblerJarService. None of this code really needs to be written in Java (it's largely just zip file manipulation and creation).

The remaining two sources built and installed in this jar are provided to bootstrap applications built by warbler (not to run warbler itself):

• JarMain: provides a "main" entry point for standalone executable jars.
• WarMain: supports the embedded web application server used for executable war files`.

These two classes could be moved to Maven modules and versioned from there. They could also be eliminated altogether:

• The JarMain class could be re-integrated back into JRuby, since it provides functionality the existing JRuby JarBootstrapMain does not. Building an executable jar would then just involve repackaging JRuby with appropriate layout and configuration to run the user's app.
• The WarMain class could be generated, or written in Ruby with a JarMain bootstrap to run the ruby and then re-dispatch to the web server's main.

Eliminating the extension would get the gem back to a pure-Ruby construct and allow it to be run from any compatible Ruby implementation.

Transplanting or eliminating the "mains" would make it possible to build the warbler gem with any compatible Ruby implementation.

[headius]

See #579 for work done to remove the jar from the repository.

[chadlwilson]

Eliminating the extension would get the gem back to a pure-Ruby construct and allow it to be run from any compatible Ruby implementation.

After having looked at this for a while, the extension is actually intended only as a "fast path" zip processing mechanism which redefines pure ruby methods in Java, however discovered that if you try and rely on this fallback-to-Ruby with rubyzip 3, warbler produces broken jars due to changes in rubyzip over time, which are not tested anywhere, since we only test with JRuby.

warbler/lib/warbler/jar.rb

Lines 306 to 337 in 06d8c82

	def create_jar(jar_path, entries)
	ZipSupport.create(jar_path) do |zipfile|
	entries.keys.sort.each do |entry|
	src = entries[entry]
	if src.respond_to?(:read)
	zipfile.get_output_stream(entry) { |f| f << src.read }
	elsif src.nil? || File.directory?(src)
	if File.symlink?(entry) && ! defined?(JRUBY_VERSION)
	warn "directory symlinks are not followed unless using JRuby; " +
	"#{entry.inspect} contents not in archive"
	end
	zipfile.mkdir(entry.dup) # in case it's frozen rubyzip 0.9.6.1 workaround
	elsif File.symlink?(src)
	zipfile.get_output_stream(entry) { |f| f << File.read(src) }
	elsif File.exist?(src)
	zipfile.add(entry, src)
	else
	warn "file not found; #{entry.inspect} not in archive"
	end
	end
	end
	end
	def entry_in_jar(jar, entry)
	ZipSupport.open(jar) do |zf|
	zf.get_input_stream(entry) {|io| StringIO.new(io.read) }
	end
	end
	# Java-boosted jar creation for JRuby; replaces #create_jar and
	# #entry_in_jar with Java version
	require 'warbler_jar' if defined?(JRUBY_VERSION)

In practice, I think there are many other things that dont work properly if not executing warbler with jruby itself, because it'll start using arbitrary bundler versions which are completely different to what the target jruby version will run with. That will likely lead to absolute chaos of the sort we've been unpicking with Warbler 2.1, because bundler has changed a lot, and lockfiles written with bundler vX are not guaranteed to work with bundler vY, or to resolve the same things, which is why bundler both locks versions and is supposed to dynamically switch versions. CRuby and JRuby usually don't match bundler versions and JRuby embedded is usually stuck on some outdated version. I have also not found a way to update ones bundler version or reliably use a version other than the stdlib/embedded one, when using jruby embedded (as is implicit to jruby-rack and warbler).

In my personal view, I'd prefer to drop usage with CRuby entirely (#649), additionally because of the reasons I outlined at #324 (comment)

But whether the native Java extension for faster zip processing is needed is debatable, probably just needs a perf test warbling something with a large number of files (e.g git gems) to see if it can be dropped at low cost. If we dropped the extension, we could possibly just compile the JarMain and WarMain files on demand (if javac available) for placement in people's wars/jars to be able to restore use of warbler from a git-sourced gem (to make development a bit less painful).