JRuby

This will be my last post on this blog. For several reasons I like the idea of keeping more in control over my blog and the environment surrounding it. I also have some things I'd like to publish that isn't well suited for the blog format, and moving ... [More] to another location means that I can keep all my content in the same place. More long term I'm planning on migrating information about my open source projects there to.But what you need to know is this: This blog ends. A new blog is born. All my old entries have been migrated. The important addresses for the new blog is: Blog: http://olabini.com/blog Feed: http://feeds.feedburner.com/olabini And that's it. The new content will obviously be available at http://olabini.com, but right now this site just redirects to the blog.The blog is dead, long live the blog. [Less]

This will be my last post on this blog. For several reasons I like the idea of keeping more in control over my blog and the environment surrounding it. I also have some things I'd like to publish that isn't well suited for the blog format, and moving ... [More] to another location means that I can keep all my content in the same place. More long term I'm planning on migrating information about my open source projects there to.But what you need to know is this: This blog ends. A new blog is born. All my old entries have been migrated. The important addresses for the new blog is:Blog: http://olabini.com/blogFeed: http://feeds.feedburner.com/olabiniAnd that's it. The new content will obviously be available at http://olabini.com, but right now this site just redirects to the blog.The blog is dead, long live the blog. [Less]

I would like to announce that ThoughtWorks Sweden is now in motion. We have business cards and an office. Everyone is returning from their long lovely Swedish summer vacations.This means that ThoughtWorks Sweden is ready, and available for work. If ... [More] you or your business have a project you need help with, don't hesitate to contact me (at [email protected]) or Marcus Ahnve (at [email protected]).We are located in Stockholm, but we are open for work anywhere in the Nordic regions.So what kind of work are we most suited for? Our sweet spot is in delivery and technical advisory regarding Java, Ruby and JRuby. And if you're interested in understanding how our Agile approach can change your company, we can do organizational transformation projects and also coaching and advisory.Don't hesitate to get in touch! [Less]

I would like to announce that ThoughtWorks Sweden is now in motion. We have business cards and an office. Everyone is returning from their long lovely Swedish summer vacations.This means that ThoughtWorks Sweden is ready, and available for work. If ... [More] you or your business have a project you need help with, don't hesitate to contact me (at [email protected]) or Marcus Ahnve (at [email protected]).We are located in Stockholm, but we are open for work anywhere in the Nordic regions.So what kind of work are we most suited for? Our sweet spot is in delivery and technical advisory regarding Java, Ruby and JRuby. And if you're interested in understanding how our Agile approach can change your company, we can do organizational transformation projects and also coaching and advisory.Don't hesitate to get in touch! [Less]

I would like to announce that ThoughtWorks Sweden is now in motion. We have business cards and an office. Everyone is returning from their long lovely Swedish summer vacations.This means that ThoughtWorks Sweden is ready, and available for work. If ... [More] you or your business have a project you need help with, don't hesitate to contact me (at [email protected]) or Marcus Ahnve (at [email protected]).We are located in Stockholm, but we are open for work anywhere in the Nordic regions.So what kind of work are we most suited for? Our sweet spot is in delivery and technical advisory regarding Java, Ruby and JRuby. And if you're interested in understanding how our Agile approach can change your company, we can do organizational transformation projects and also coaching and advisory.Don't hesitate to get in touch! [Less]

There still seems to be confusion about the relative simplicity or difficulty of deploying a Rails app using JRuby. Many folks still look around for the old tools and the old ways (Mongrel, generally), assuming that "all that app server stuff" is too ... [More] complicated. I figured I'd post a quick walkthrough to show how easy it actually is, along with links to everything to get you started.Here's the full session, in all its glory, for those who just want the commands:~/work ➔ java -Xmx256M -jar ~/Downloads/glassfish-installer-v2ur2-b04-darwin.jar~/work ➔ cd glassfish~/work/glassfish ➔ chmod a x lib/ant/bin/*~/work/glassfish ➔ lib/ant/bin/ant -f setup.xml~/work/glassfish ➔ bin/asadmin start-domain~/work/glassfish ➔ cd ~/work/testapp~/work/testapp ➔ jruby -S gem install warbler~/work/testapp ➔ jruby -S gem install activerecord-jdbcmysql-adapter~/work/testapp ➔ vi config/database.yml~/work/testapp ➔ warble~/work/testapp ➔ ../glassfish/bin/asadmin deploy --contextroot / testapp.warNow, on to the full walkthrough!PrerequisitesJRuby 1.1.3 or higherNone of the steps in the main walkthrough require JRuby, since Warbler works fine under other Ruby implementations. But if you want to install and test against the JDBC ActiveRecord adapters, JRuby's the way. And in general, if you're deploying on JRuby, you should probably test and build on JRuby as well. Go to www.jruby.org under "Download!" and grab the latest 1.1.x "bin" distribution. I link here JRuby 1.1.3 tarball and JRuby 1.1.3 zip for your convenience. Download, unpack, put in PATH. That's all there is to it.Java 5 or higherMost systems already have a JVM installed. Here's some links to OpenJDK downloads for various platforms, in case you don't already have one.Windows, Linux, Solaris: Download the JDK directly from Sun's Java SE Downloads page. I typically download the JDK (Java Development Kit) because I find it convenient to have Java sources, compilers, and debugging tools available, but this walkthrough should work with the JRE (Java Runtime Environment) as well. Linux and Solaris users should also be able to use their packaging system of choice to install a JDK.OS X: The 32-bit Intel macs can't run the Apple Java 6, so you'll want to look at the Soylatte Java 6 build for OS X to get the best performance. A small warning...it doesn't have Cocoa-based UI components, so it will use X11 if you start up a GUI app.BSDs: FreeBSD users should check the FreeBSD Java downloads page. I believe there's a port for FreeBSD and package/port for OpenBSD but I couldn't dig up the details. We have had users on both platforms, though, so I know they work fine.Others: There's basically a JDK for just about every platform, so if you're not on one of these just do a little digging. All you need to know is that it needs to be a full Java 5 or higher implementation.Rails 2.0 or higherHopefully by now most of you are on a 2.x version of Rails. This walkthrough will assume you've got Rails 2.0 installed. If you're using JRuby, it's a simple "jruby -S gem install rails" or if you've got JRuby's bin in PATH, "gem install rails" should do the trick. Note that the Warbler (described later) should work in any Ruby implementation, since it's just a packager and it includes JRuby.Step One: The App ServerThe words "Application Server" are terrifying to most Rubyists, to the point that they'll refuse to even try this deployment model. Of course, the ones that try it usually agree it's a much cleaner way to deploy apps, and generally they don't want to go back to any of the alternatives.Much of the teeth-gnashing seems to surround the perceived complexity of setting a server up. That was definitely the case 5 years ago, but today's servers have been vastly simplified. For this walkthrough, I'll use GlassFish, since it's FOSS, fast, and easy to install.I'm using GlassFish V2 UR2 (that's Version 2, Update Release 2) since it's very stable and by most accounts the best app server available, FOSS or otherwise. Not that I'm biased or anything. At any rate, it's hard to argue with the install process.1. Download from the GlassFish V2 UR2 download page. The download links start about halfway down the page and are range from 53MB (English localization) to 93MB (Multilanguage) in size.2. Run the GlassFish installer. The .jar file downloaded is an executable jar containing the installer for GlassFish as well as GlassFish itself. The -Xmx specified here increases the memory cap for the JVM from its default 64MB to 256MB, since the archive gets unpacked in memory.~/work ➔ java -Xmx256M -jar ~/Downloads/glassfish-installer-v2ur2-b04-darwin.jarglassfishglassfish/docsglassfish/docs/cssglassfish/docs/figures...glassfish/updatecenter/READMEglassfish/updatecenter/registry/SYSTEM/local.xmlinstallation complete~/work ➔ Before the unpack begins, the installer will pop up a GUI asking you to accept the GlassFish license.Read the license or not...it's up to you. But to accept, you need to at least pretend you read it and scroll the license to the bottom.The installer will proceed to unpack all the files for GlassFish into ./glassfish.3. Run the GlassFish setup script. In the unpacked glassfish directory, there are two .xml files: setup.xml and setup-cluster.xml. Most users will just want to use setup.xml here, but if you're interested in clustering several GlassFish instances across machine, you'll want to look into the clustered setup. I won't go into it here.The unpacked glassfish dir also contains Apache's Ant build tool, so you don't need to download it. If you already have it available, your copy should work fine, and the chmod command below--which sets the provided Ant's bin scripts executable--would be unnecessary. If you're on Windows, the bin scripts are bat files, so they'll work fine as-is.Two items to note: you should probably move the glassfish dir where you want it to live in production, and you should run the installer with the version of Java you'd like GlassFish to run under. Both can be changed later, but it's better to just get it right the first time.~/work ➔ cd glassfish~/work/glassfish ➔ chmod a x lib/ant/bin/*~/work/glassfish ➔ lib/ant/bin/ant -f setup.xmlBuildfile: setup.xmlall:[mkdir] Created dir: /Users/headius/work/glassfish/binget.java.home:setup.init:...jar-unpack:[unpack200] Unpacking with Unpack200[unpack200] Source File :/Users/headius/work/glassfish/lib/appserv-cmp.jar.pack.gz[unpack200] Dest. File :/Users/headius/work/glassfish/lib/appserv-cmp.jar[delete] Deleting: /Users/headius/work/glassfish/lib/appserv-cmp.jar.pack.gz...do.copy.unix:[copy] Copying 1 file to /Users/headius/work/glassfish/config[copy] Copying 1 file to /Users/headius/work/glassfish/bin[copy] Copying 1 file to /Users/headius/work/glassfish/bin...create.domain:[exec] Using port 4848 for Admin.[exec] Using port 8080 for HTTP Instance.[exec] Using port 7676 for JMS....BUILD SUCCESSFULTotal time: 29 seconds~/work/glassfish ➔ 4. Start up your GlassFish server. It's as simple as one command now.~/work/glassfish ➔ bin/asadmin start-domainStarting Domain domain1, please wait.Log redirected to /Users/headius/work/glassfish/domains/domain1/logs/server.log.Redirecting output to /Users/headius/work/glassfish/domains/domain1/logs/server.logDomain domain1 is ready to receive client requests. Additional services are being started in background.Domain [domain1] is running [Sun Java System Application Server 9.1_02 (build b04-fcs)] with its configuration and logs at: [/Users/headius/work/glassfish/domains].Admin Console is available at [http://localhost:4848].Use the same port [4848] for "asadmin" commands.User web applications are available at these URLs:[http://localhost:8080 https://localhost:8181 ].Following web-contexts are available:[/web1 /__wstx-services ].Standard JMX Clients (like JConsole) can connect to JMXServiceURL:[service:jmx:rmi:///jndi/rmi://charles-nutters-computer.local:8686/jmxrmi] for domain management purposes.Domain listens on at least following ports for connections:[8080 8181 4848 3700 3820 3920 8686 ].Domain does not support application server clusters and other standalone instances.~/work/glassfish ➔ Congratulations! You have installed GlassFish. Simple, eh?A few tips for using your new server:There's a web-based admin page at http://localhost:4848 where the admin login is admin/adminadmin by default. You'll want to change that password. Select "Application Server" on the left and then "Administrator Password" along the top.Poke around the admin console to get a feel for the services provided. You won't need any of them for the rest of this walkthrough, but you might want to dabble some day. And if you want to set up a connection pool later on (which ActiveRecord-JDBC supports) this is where you'll do it.Most folks will probably want to set up init scripts to ensure GlassFish is launched at server startup. That's outside the scope of this walkthrough, but it's pretty simple. I'll update this page (and it's equivalent on the JRuby Wiki) once I know more.GlassFish works just fine as a standalone server, but many users will want to proxy it through Apache or another web server. Again, this is outside the scope of this walkthrough, but it should be as simple as configuring a virtual host or a set of matching URLs to hit the GlassFish server at port 8080 (which is the default port for web applications). For apps I'm running, however, I just use GlassFish.Step 2: Package your AppThis step is made super-trivial by Nick Sieger's Warbler. It includes JRuby itself and provides a simple set of commands to package up your app, add a packaging config file, and more. In this case, I'll just be packaging up a simple Rails app.Note that Warbler works just fine under non-JRuby Ruby implementations, since it's all Ruby code. But again, if you're deploying with JRuby, it's probably a good idea to test and build with JRuby as well.~/work ➔ jruby -S gem install warblerSuccessfully installed warbler-0.9.101 gem installedInstalling ri documentation for warbler-0.9.10...Installing RDoc documentation for warbler-0.9.10...~/work ➔ cd testapp~/work/testapp ➔ ls .README Rakefile app config db doc lib log public script test tmp vendor~/work/testapp ➔ warblejar cf testapp.war -C tmp/war .~/work/testapp ➔ And that's essentially all there is to it. You will get a .war file containing your app, JRuby, Rails, and the Ruby standard library. This one file is now a deployable Rails applications, suitable for any app server, any OS, and any platform without a recompile. The target server doesn't even have to have JRuby or Rails installed.Step 3: Deploy your ApplicationThere's two ways you can deploy. You can either go to the Admin Console web page, select "Web Applications" from the "Applications" category on the left, and deploy the file there, or you can just use GlassFish's command-line interface. I will demonstrate the latter, and I'm providing the optional contextroot flag to deploy my app at the root context.~/work/testapp ➔ ../glassfish/bin/asadmin deploy --contextroot / testapp.warCommand deploy executed successfully.~/work/testapp ➔ That's it? Yep, that's it! If we now hit the server at port 8080, we can see the app is deployed.Step 4: TweakingThere's a few things you can do to tweak your deployment a bit. The first would be to generate a warble.rb config file and adjust settings to suit your application.~/work/testapp ➔ warble config~/work/testapp ➔ head config/warble.rb# Warbler web application assembly configuration fileWarbler::Config.new do |config|# Temporary directory where the application is staged# config.staging_dir = "tmp/war"# Application directories to be included in the webapp.config.dirs = %w(app config lib log vendor tmp)...In this file you can set the min/max number of Rails instances you need, additional files and directories to include, additional gems and libraries to include, and so on. The file is heavily commented, so you should have no trouble figuring it out, but otherwise the Warbler page on the JRuby Wiki is probably your best source of information. And since a lot of people ask how many instances they should use, I'll provide a definitive answer: it depends. Try the defaults, and scale up or down as appropriate. Hopefully with Rails 2.2 this will no longer be needed, as is the case for Merb and friends.The other tweak you'll probably want to look into is using the JDBC-based ActiveRecord adapters instead of the pure Ruby versions (or the C-based versions, if you're migrating from the C-based Ruby impls). This is generally pretty simple too. Install the JDBC adapter for your database, and tweak your database.yml. Here's the commands on my system:~/work/testapp ➔ jruby -S gem install activerecord-jdbcmysql-adapterSuccessfully installed jdbc-mysql-5.0.4Successfully installed activerecord-jdbcmysql-adapter-0.8.22 gems installedInstalling ri documentation for jdbc-mysql-5.0.4...Installing ri documentation for activerecord-jdbcmysql-adapter-0.8.2...Installing RDoc documentation for jdbc-mysql-5.0.4...Installing RDoc documentation for activerecord-jdbcmysql-adapter-0.8.2...~/work/testapp ➔ vi config/database.yml~/work/testapp ➔ And the modified database.yml file:...# This was changed from "adapter: mysql"production:adapter: jdbcmysqlencoding: utf8...Now repackage ("warble" command again), redeploy, and you're done!ConclusionHopefully this walkthrough clears up some confusion around JRuby on Rails deployment to an app server. It's really a simple process, despite the not-so-simple history surrounding Enterprise Application Servers, and GlassFish almost makes it fun :) [Less]

There's been a little bit of buzz about David Heinemeier Hansson's announcement that Josh Peek has joined Rails core and is about to wrap up his GSoC project making Rails finally be thread-safe. To be honest, there probably hasn't been enough buzz ... [More] , and there's been several misunderstandings about what it means for Rails users in general.So I figured I'd do a really short Q/A about what effect Rails thread-safety would have on the Rails world, and especially the JRuby world. Naturally there's some of my opinions reflected here, but most of this should be factually correct. I trust you will offer corrections in the comments.Q: What does it mean to make Rails thread-safe?A: I'm sure Josh or Michael Koziarski, his GSoC mentor, can explain in more detail what the work involved, but basically it means removing the single coarse-grained lock around every incoming request and replacing it with finer-grained locks around only those resources that need to be shared across threads. So for example, data structures within the logging subsystem have either been modified so they are not shared across threads, or locked appropriately to make sure two threads don't interfere with each other or render those data structures invalid or corrupt. Instead of a single database connection for a given Rails instance, there will be a pool of connections, allowing N database connections to be used by the M requests executing concurrently. It also means allowing requests to potentially execute without consuming a connection, so the number of live, active connections usually will be lower than the number of requests you can handle concurrently.Q: Why is this important? Don't we have true concurrency already with Rails' shared-nothing architecture and multiple processes?A: Yes, processes and shared-nothing do give us full concurrency, at the cost of having multiple processes to manage. For many applications, this is "good enough" concurrency. But there's a down side to requiring as many processes as concurrent requests: inefficient use of shared resources. In a typical Mongrel setup, handling 10 concurrent requests means you have to have 10 copies of Rails loaded, 10 copies of your application loaded, 10 in-memory data caches, 10 database connections...everything has to be scaled in lock step for every additional request you want to handle concurrently. Multiply the N copies of everything times M different applications, and you're eating many, many times more memory than you should.Of course there are partial solutions to this that don't require thread safety. Since much of the loaded code and some of the data may be the same across all instances, deployment solutions like Passenger from Phusion can use forking and memory-model improvements in Phusion's Ruby Enterprise Edition to allow all instances to share the portion of memory that's the same. So you reduce the memory load by about the amount of code and data in memory that each instance can safely hold in common, which would usually include Rails itself, your static application code, and to some extent the other libraries loaded by Rails and your app. But you still pay the duplication cost for database connections, application code, and in-memory data that are loaded or created after startup. And you still have "no better" concurrency than the coarse-grained locking since Ruby Enterprise Edition is is just as green-threaded as normal Ruby.Q: So for green-threaded implementations like Ruby, Ruby EE, and Rubinius, native threading offers no benefit?A: That's not quite true. Thread-safe Rails will mean that an individual instance, even with green threads, can handle multiple requests at the same time. By "at the same time" I don't mean concurrently...green threads will never allow two requests to actually run concurrently or to utilize multiple cores. What I mean is that if a given request ends up blocking on IO, which happens in almost all requests (due to REST hits, DB hits, filesystem hits and so on), Ruby will now have the option of scheduling another request to execute. Put another way, removing the coarse-grained lock will at least improve concurrency up to the "best" that green-threaded implementations can do, which isn't too bad.The practical implication of this is that rather than having to run a Rails instance for every process you want to handle at the same time, you will only have to run a certain constant number of instances for each core in your system. Some people use N 1 or 2N 1 as their metric to map from cores (N) to the number of instances you would need to effectively utilize those cores. And this means that you'd probably never need more than a couple Rails instances on a one-core system. Of course you'll need to try it yourself and see what metric works best for your app, but ultimately even on green-threaded implementations you should be able to reduce the number of instances you need.Q. Ok, what about native-threaded implementations like JRuby?A. On JRuby, the situation improves much more than on the green-threaded implementations. Because JRuby implements Ruby threads as native kernel-level threads, a Rails application would only need one instance to handle all concurrent requests across all cores. And by one instance, I mean "nearly one instance" since there might be specific cases where a given application bottlenecks on some shared resource, and you might want to have two or three to reduce that bottleneck. In general, though, I expect those cases will be extremely rare, and most would be JRuby or Rails bugs we should fix.This means what it sounds like: Rails deployments on JRuby will use 1/Nth the amount of memory they use now, where N is the number of thread-unsafe Rails instances currently required to handle concurrent requests. Even compared to green-threaded implementations running thread-safe Rails, it willl likely use 1/Mth the memory where M is the number of cores, since it can parallelize happily across cores with only "one" instance.Q: Isn't that a huge deal?A: Yes, that's a huge deal. I know existing JRuby on Rails users are going to be absolutely thrilled about it. And hopefully more folks will consider using JRuby on Rails in production as a result.And it doesn't end at resource utilization in JRuby's case. With a single Rails instance, JRuby will be able to "warm up" much more quickly, since code we compile and optimize at runtime will immediately be applicable to all incoming requests. The "throttling" we've had to do for some optimizations (to reduce overall memory consumption) may no longer even be needed. Existing JDBC connection pooling support will be more reliable and more efficient, even allowing connection sharing from application to application as well as across instances. And it will put Rails on JRuby on par with other frameworks that have always been (probably) thread-safe like Merb, Groovy on Grails, and all the Java-based frameworks.Naturally, I'm thrilled. :) [Less]

JtestR allows you to test your Java code with Ruby frameworks.Homepage: http://jtestr.codehaus.orgDownload: http://dist.codehaus.org/jtestrJtestR 0.3.1 is the current release of the JtestR testing tool. JtestR integrates JRuby with several Ruby ... [More] frameworks to allow painless testing of Java code, using RSpec, Test/Unit, Expectations, dust and Mocha.Features:- Integrates with Ant, Maven and JUnit- Includes JRuby 1.1, Test/Unit, RSpec, Expectations, dust, Mocha and ActiveSupport- Customizes Mocha so that mocking of any Java class is possible- Background testing server for quick startup of tests- Automatically runs your JUnit and TestNG codebase as part of the buildGetting started: http://jtestr.codehaus.org/Getting+StartedNew in the 0.3.1 release is upgrade of JRuby to revision r7479 which includes several new Java Integration features, upgrading of ActiveSupport to 2.1.0, fixing a severe memory leak in the background server and some minor usability features.New and fixed in this release:JTESTR-50 Difference in functionality when stubbing a method on a Java class vs a Ruby class using mochaJTESTR-51 Mocking of classes lacking default constructors results in a NameErrorJTESTR-53 Push the JtestR JRuby builds to maven reposJTESTR-56 Upgrade ActiveSupportJTESTR-57 Make it possible to use local versions of libraries.JTESTR-59 No output when no tests found.JTESTR-60 OutOfMemoryErrorJTESTR-61 Documentation improvments - ant test-serverJTESTR-62 Having the jtestr.jar in the base directory doesn't workJTESTR-63 Update JRuby version [Less]

JtestR allows you to test your Java code with Ruby frameworks.Homepage: http://jtestr.codehaus.orgDownload: http://dist.codehaus.org/jtestrJtestR 0.3.1 is the current release of the JtestR testing tool. JtestR integrates JRuby with several Ruby ... [More] frameworks to allow painless testing of Java code, using RSpec, Test/Unit, Expectations, dust and Mocha.Features:- Integrates with Ant, Maven and JUnit- Includes JRuby 1.1, Test/Unit, RSpec, Expectations, dust, Mocha and ActiveSupport- Customizes Mocha so that mocking of any Java class is possible- Background testing server for quick startup of tests- Automatically runs your JUnit and TestNG codebase as part of the buildGetting started: http://jtestr.codehaus.org/Getting+StartedNew in the 0.3.1 release is upgrade of JRuby to revision r7479 which includes several new Java Integration features, upgrading of ActiveSupport to 2.1.0, fixing a severe memory leak in the background server and some minor usability features.New and fixed in this release:JTESTR-50 Difference in functionality when stubbing a method on a Java class vs a Ruby class using mochaJTESTR-51 Mocking of classes lacking default constructors results in a NameErrorJTESTR-53 Push the JtestR JRuby builds to maven reposJTESTR-56 Upgrade ActiveSupportJTESTR-57 Make it possible to use local versions of libraries.JTESTR-59 No output when no tests found.JTESTR-60 OutOfMemoryErrorJTESTR-61 Documentation improvments - ant test-serverJTESTR-62 Having the jtestr.jar in the base directory doesn't workJTESTR-63 Update JRuby version [Less]

JtestR allows you to test your Java code with Ruby frameworks.Homepage: http://jtestr.codehaus.orgDownload: http://dist.codehaus.org/jtestrJtestR 0.3.1 is the current release of the JtestR testing tool. JtestR integrates JRuby with several Ruby ... [More] frameworks to allow painless testing of Java code, using RSpec, Test/Unit, Expectations, dust and Mocha.Features:- Integrates with Ant, Maven and JUnit- Includes JRuby 1.1, Test/Unit, RSpec, Expectations, dust, Mocha and ActiveSupport- Customizes Mocha so that mocking of any Java class is possible- Background testing server for quick startup of tests- Automatically runs your JUnit and TestNG codebase as part of the buildGetting started: http://jtestr.codehaus.org/Getting StartedNew in the 0.3.1 release is upgrade of JRuby to revision r7479 which includes several new Java Integration features, upgrading of ActiveSupport to 2.1.0, fixing a severe memory leak in the background server and some minor usability features.New and fixed in this release:JTESTR-50 Difference in functionality when stubbing a method on a Java class vs a Ruby class using mochaJTESTR-51 Mocking of classes lacking default constructors results in a NameErrorJTESTR-53 Push the JtestR JRuby builds to maven reposJTESTR-56 Upgrade ActiveSupportJTESTR-57 Make it possible to use local versions of libraries.JTESTR-59 No output when no tests found.JTESTR-60 OutOfMemoryErrorJTESTR-61 Documentation improvments - ant test-serverJTESTR-62 Having the jtestr.jar in the base directory doesn't workJTESTR-63 Update JRuby version [Less]