Admission: I was a bit rash to have declared Jihad on Maven back in December. (Is it ever wise to write “Jihad” on your blog?) Now 10 months later I’m still using Maven to build java and manage cross-java dependencies at build time. In the interest of peace and reconciliation let me say that Maven has really been performing amiably in its now reduced responsibility of invoking javac with a proper classpath, and packaging jars from the results. While this stalemate still seems less than ideal, I think I might continue to be able to get along with Maven, provided I don’t need to write any “plugins” for it, or wrestle with it for any less well trodden tasks.

Besides the war mongering, the original post does manage to outline the goals and associated set of issues around building gems for JRuby with java jars included. I’ve had good success with this strategy for releasing componentized systems to both dedicated colo and Amazon EC2 production environments in the last year. Enough so that investing some more time in build automation has become warranted. This comes in the form of a new Rake helper gem called TarPit, released as part of the RJack project. What was a very wet and copied around jars-in-gem rakefile recipe, can now be expressed in a short and declarative style. For example, the rjack-logback Rakefile:

require 'rjack-tarpit'

t = 'rjack-logback', RJack::Logback::VERSION )

t.specify do |h|
  h.developer( "David Kellum", "" )
  h.extra_deps << [ 'rjack-slf4j', '~> 1.5.8' ]
  h.rubyforge_name = "rjack"
  h.remote_rdoc_dir = "logback"

t.jars = %w{ core classic access }.map do |n|
  "logback-#{n}-#{ RJack::Logback::LOGBACK_VERSION }.jar"

file 'Manifest.txt' => [ "lib/#{}/base.rb" ]

t.assembly_version = 1.0


How it all works