The RJack project has expanded its mission in providing common open-source java components as gems for use with JRuby.
When I started RJack with the slf4j and logback gems, I figured I was pretty safe in using these names verbatim, since the gems were a very minimal and direct packaging of the same named upstream projects. Same with the jetty inclusion. Over time however I found potential inclusions colliding with existing ruby gems, for example: hc-httpclient was so named because httpclient, not surprisingly, was not available. With the later additions a certain rjack style also started to jell:
SLF4J is the logging interface: every included rjack gem will use it to resolve java logging dependencies where found, including via legacy interfaces like commons logging, etc.
RJack will strive to expose every aspect of component setup, which might be referred to as “configuration” in the upstream java project, as easy to use and extend ruby classes, instead of less flexible XML, YAML, or the like.
When appropriate and useful, RJack gems will include ruby adapters to make these components more amendable to direct use from ruby code.
Given these stylistic choices, and in order to better consolidate the effort and prepare for further expansion, I’ve decided at this point to release new versions of the existing gems under a “rjack-“ gem prefix name and ::RJack ruby module. The following table shows old and new names and the current release version. New rjack-gems are also shown.
| Old Name | New Name | Updated Version |
|---|---|---|
| slf4j | rjack-slf4j | 1.5.8.1 |
| logback | rjack-logback | 0.9.17.1 |
| hc-httpclient | rjack-httpclient-3 | 3.1.3 |
| - | rjack-httpclient-4 | 4.0.0 |
| jetty | rjack-jetty | 6.1.20.1 |
| jetty-jsp | rjack-jetty-jsp | 6.1.20.2.1.1 |
| - | rjack-commons-codec | 1.4.0 |
| - | rjack-commons-dbcp | 1.2.2.0 |
| - | rjack-commons-dbutils | 1.2.0 |
| - | rjack-commons-pool | 1.5.3.0 |
The rjack-httpclient-[3,4] gems were a special consideration. I maintain continuity between the two versions, and the ruby setup interfaces are compatible, but require’ing both versions in the same process is permissible (like the associated Java code). This supports incremental transition to 4.x, a reality given lack of backward compatibility in the java interface and lack of significant pressure to migrate from 3.x.
In my other projects that use these gems, I’ve found converting to the new names a pretty easy grep and replace operation. Since they are also some cross dependencies between these gems, I recommend transition en masse. The gems with the old names will remain in the RubyForge gem repo, and significant bug fixes can be back ported if needed.
Finally, there are some other new features included:
The SLF4J gem now has better support for both ruby and java exceptions logged from ruby, and in mapping Ruby Module::Class names into java/SLF4J Logger dot notation.
Mapped Diagnostic Content support in SLF4J and Logback
A new reusable jar-in-gem build tool, rjack-tarpit the subject of a future post.