JRuby application packaging P-1

Any Info which regards the packaging of JRuby applications is quite scarce, in Java the options are clear and for the most part there is only one option (jar as you might have guessed already), jars aren't designed to carry Ruby code within them, they don't mix with the Ruby ecosystem too well (the interpreter cant run them directly, not without some wrapping) and they force some adjustments (like a Main Java class as an entry point).
Luckily JRuby does support Ruby's packaging system (rubygems) which offers some interesting options, still there are some pitfalls and issues to solve such as:

• The creation/installation/distribution of a JRuby gem.


• Jars and gems mixing (what is the correct mixture?).


• Automation and build integration.

In this post and the following one ill try to introduce some solutions to these issues starting with the basic gem packaging procedure.

A useful tool for dealing with gems is newgem, newgem is a command line utility which generates a skeleton of folders & files, this approach is the easiest way to get going:

 newgem dummy # our dummy project gem  

the resulting dummy folder will contain:

History.txt   Rakefile lib setup.rb 
License.txt   log tasks   website
Manifest.txt  config pkg test
README.txt    doc script  tmp

The lib folder is the destination of our Ruby code, at its post creation state this folder contains an empty folder which carries the application name and a single matching ruby script:

$:.unshift File.dirname(__FILE__)

module AppName

end

This script is the gateway to your application (it includes the first lines of code that will be executed upon gem requiring), in its naked form it only adds the code under the lib/app_name path to the interpreter's load path variable (LOAD_PATH aka $: which is an array), this will enable access to the the rest of the code:

# this loads up the gem
gem 'dummy'
# this will load up lib/dummy.rb and add /lib/dummy to $:
require 'dummy'
# now we may require any other piece of code under dummy
require 'dummy/bla'

Any to be packaged file & folder should have its name appended to the Manifest.txt file.

All that is left in order to package our code into a gem is to invoke:

rake package # The resulting gem will be placed under the pkg folder.
jruby -S gem pkg/app_name_version.gem # this will install it into the JRuby environment 

Another nice feature that newgem offers is the ability to create a binary command (like rake, rails) which is integrated into the Ruby environment along side the gem installation:

ruby script/generate executable dummy # run this under the generated folder path

This will generate a bin folder which contains a single file, all that is left is to append the desired functionality at the bottom of this file and add it to the Manifest.txt.

Summary:
In this post wev'e taken a look on basic gem creation, on the next one ill explain how to inject jar's into our gem and take a look on some automated newgem manipulation with buildr & rake.

Getting ahead with the program

Well it's been a week since my last post (time moves fast isn't it?) and had the need to write about some new idea's/solutions/stuff that iv found, so without further ado:

In the gookup front iv made some progress with the packging scheme of the application, the problem is that Ruby/JRuby programs need to have at least a parser installed in order to work (well almost true since for Ruby you may use somthing like RubyScript2Exe), still i don't want to make my users have to install JRuby (the only requirement that im willing to live with is the need to have a working >1.5 JRE).
After goggling quite a bit iv found two main approaches, the first is to use a main Java class as an entry point to your JRuby main code and package the whole application in a Jar, the down side with this approach is that it doesn't seem to answer how to package ruby gems that your application requires in a clean manner (a possible answer might be to use something like JRubyGems ).
The second approach is to use jruby-complete.jar and create a working JRuby environment as a part of your install process with something like this:

 java -Xmx512m -jar jruby-complete.jar --command gem install gem-name

This will create a gem library under .jruby (or any custom library with the -Djruby.home=/custom/path flag) onto required gems will be installed.
In order to run your JRuby main code all you need to do is to issue:

 java -Xmx512m -jar jruby-complete.jar --command main.rb

Iv not decided which one of them ill eventually use (if any), the nice things about these kind of projects is how they evolve and grow.

Another two related tidbits:

• Since this application will be command line base iv decided to look for a Ruby library that will save me the trouble of parsing commands from the user, cmdparse seems to meet my expectations, not only does it have an nice design but also a default help and version commands by default.
  


• Another issue which bothered me along the development process was the lack of a debugger in my IDE, im used to the Intellij debbuger but it doesn't seem to support JRuby code yet (Netbeans does), ruby-debug seems to be have ported to JRuby (haven't tested it yet) and from this screen cast it looks pretty awesome!
  

In the Flex front iv been taking baby steps in trying to figure out how things are related to each other, iv noticed is that Adobe has a tendency to rename things quite a lot (marketing takes it tall i guess), so that Flex Data Services is now called LiveCycle Data services, LiveCycle consists of a couple of parts of functionality out of which im only interested (at the moment) in Flex remoting services and the way that they interact with Java backends, this small fraction of functionality is distributed in a OSS distribution named BlazeDS project.
One frustrating thing that iv noticed is that Flex 2 compiled SWF's aren't compilable with latest BlazeDS, iv learned this the hard way following this simplistic getting started guide, (My bad it seems as if i haven't passed mxmlc flags during compilation)
iv learned that Flex RIA has couple of remote call options, one of which is RPC-type services which basically enable Flex RIA's to call remote Pojo methods and cosume the return values that they produce, its also possible to call managed Spring beans methods by using a custom factory.

Im planing to develope some toy project that will incorperate Flex, Spring and Hibernate, ill share my experience here so stay tuned!

Yet another informational post (yaip)

After not writing for some time in this blog iv decided that i should post more regularly and share cool ideas/technologies that i encounter on daily/weekly bases, my agenda these days revolves around some of the following:

• gookup - a Google services backup utility which takes your valuable online data and stores it localy on your hard drive for safe keeping.
  Iv been working on it for the past couple of months, the nice thing about it (besides its usefulness i hope) is the fact that its fully JRuby based & uses Buildr as its build tool.
  This matching allows some intresting combination like 'auto' Jar requiring in our JRuby code via the usage of the artifacts that we define in our build (ill elaborate on this on some other post).
  


• Another subject that will keep me busy in the couple of following weeks is Flex, this nifty piece of technology will be a main part of projects that ill take part in the near future.
  My plan is to study the following subjects:Flex Basics, Flex & Java/Tomcat integration, Cairngorm.
  So far iv taken a look on Flex Builder (current idea support should get better on 7.0.3) and some online resources such as thirty-minute Flex test drive .
  Still the best way to study a new technology is by getting your hands dirty and actually building something with it (ill figure something up).
  


• Last but not least is Adobe AIR and JavaFX, im considering using one of the two for gookup front end (AIR dosn't support linux yet), still i might just use swing and profligacy instead if the integration with JRuby will prove to be impossible.