buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Victor Hugo Borja" <>
Subject Buildr's nailgun server running on JRuby
Date Wed, 05 Mar 2008 19:58:45 GMT
Hi all,

Just to tell you Buildr trunk now provides nailgun tasks when running within
Testers/comments are more than welcome.

  --- Current nailgun documentation follows ---

Using BuildrServer(Buildr 1.3.0 (JRuby 1.1RC2), localhost, 2113)

  NailGun is a client, protocol, and server for running Java
  programs from the command line without incurring the JVM
  startup overhead. Nailgun integration is currently available
  only when running Buildr with JRuby.

  Buildr provides a custom nailgun server, allowing you to
  start a single JVM and let buildr create a queue of runtimes.
  These JRuby runtimes can be cached (indexed by buildfile path)
  and reloaded when the buildfile has been modified.
  Runtime caching allows you to execute tasks without
  spending time creating the buildr environment. Some nailgun
  tasks have been provided to manage the cached runtimes.

  To start the buildr server execute the ng:start task.

  Configuration and Environment Variables.

  Before starting the server, buildr will check if you have
  nailgun already installed by seeking the nailgun jar under


  You can override this environment variable to tell buildr where
  to find or where to install nailgun. If missing, NAILGUN_HOME
  defaults to the $JRUBY_HOME/tools/nailgun directory. You can
  also specify the nailgun_home on your buildfile with the following

  require 'java/nailgun'
  Buildr::Nailgun.home = File.expand_path('~/.jruby/tools/nailgun')

  Buildr will also check that the nailgun client binary (ng.exe for
  Windows systems, ng otherwise) is installed on NAILGUN_HOME.
  If no binary is found, buildr will download nailgun and
  compile+install it.

  The buildr server binds itself to localhost, port 2113. You can
  override this on your buildfile, by placing the following code:

  require 'java/nailgun'
  Buildr::Nailgun.server = ''
  Buildr::Nailgun.port = 2233

  Once started, if you provided custom host/port settings you need
  to tell the nailgun client where to connect to:

  ng --nailgun-server --nailgun-port 2233 ng:tasks

  The buildr server starts a BuildrFactory responsible for providing
  a pool of JRuby runtimes configured and ready for task execution.
  This BuildrFactory consists of two queues: One of pure JRuby runtimes
  with almost nothing loaded, and another of Buildr runtimes (consumed
  from the first queue) with the Buildr runtime preloaded but without
  any project definition. The jruby queue is used for sandboxing code
  like running GetoptLong, but most importantly its the place where
  buildr runtimes begin life, to be later added on the buildr queue.
  By default both queues are of size 3, you can customize this with:

  require 'java/nailgun'
  Buildr::Nailgun.jruby_queue_size = 4 # JRuby creation is fast!
  Buildr::Nailgun.buildr_queue_size = 5 # loading buildr takes longer

  The buildr_queue_size is of particular importance if you expect to
  reload lots of buildfiles.

  Execute ng:tasks get an overview of available nailgun tasks.

Nailgun tasks:

      Display nailgun help

      Start the Nailgun server.

      Stop the Nailgun server.

      Display this message

      Display a list of builfile paths having an associated
      buildr runtime. Having a cached runtime reduces buidlr
      execution time.

      If buildr finds the current buildfile on this list,
      no file loading will be performed, only execution of
      specified tasks on the previously loaded environment.
      However if the cached runtime is out of date (buildfile
      has been modified) the runtime will be reloaded.

      This feature becomes handy when performing development
      cycle: edit -> compile -> test -> report.

      This task exits inmediatly after printing the file list.

      Remove all cached buildr runtimes and exit

  ng:add [tasks] | ng:put [tasks]
      Add or update a cached runtime.

      Use this task to create a cached buildr runtime for a

  ng:del | ng:delete
      Delete cached runtime for a buildfile and exit.

  ng:once [tasks]
      Ignore cached runtime and perform tasks on a newly
      created environment. This new runtime is dropped right
      after buildr completion.


Quaerendo invenietis.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message