The Mercurial project has just released its version 1.0!

Congratulations to the team behind this project for bringing what I personally consider as the very best distributed source configuration management tool to date (yes, I have already played with Bazaar and Git)

Mercurial is (much like Bazaar) written in Python. It is cross-platform, extremely efficient, extensible with plugins and last but not least, Mercurial is such a stupid tool to use! The interface and general workflow are no-brainers if you have already played with SCM before. You’ll get started in just a few minutes with it. I know that lots of geeks prefer playing with Git… but how can anyone understand the Git interface?

If you are currently considering a distributed SCM model, then I strongly suggest that you look at it, just like Mozilla and Sun did. Oh and if you happen to work with Windows boxes, there is still TortoiseHG for a seamless integration with the Windows explorer!

Mon manuscrit de thèse sera rédigé en LaTeX (le premier qui me parle de Word se fera frapper avec violence ) et histoire d’automatiser les choses, j’ai écrit un script de compilation en Ruby.

J’aurai pu utiliser un Makefile, un des scripts existants (il y en a un très bien en Perl dont j’ai oublié le nom), du Python, du Groovy… mais ce script là me va très bien !

#!/usr/bin/env ruby
 
require 'optparse'
require 'fileutils'
 
MAIN_FILE = "phd-thesis"
PDFLATEX  = "pdflatex #{MAIN_FILE}.tex"
BIBTEX    = "bibtex #{MAIN_FILE}.aux"
 
def build_pdf
  return unless system PDFLATEX
  return unless system BIBTEX
  callcc do |stop_build|
    3.times do
      status = system PDFLATEX
      stop_build.call unless status
    end
  end
end
 
def single_compilation
  system PDFLATEX
end
 
def clean_artifacts
  extensions = %w[blg log pdf aux bbl lof lot out toc tps]
  files = extensions.map { |ext| "#{MAIN_FILE}.#{ext}" }
  FileUtils::Verbose::rm files, { :force => true }
end
 
def open_pdf(how)
  system "#{how} #{MAIN_FILE}.pdf"
end
 
def run
  options = {
    :command => :pdf
  }
  OptionParser.new do |opts|
    opts.banner = "Usage: build.rb [options]"
 
    opts.on("--pdf", "Build the PDF output (default)") do |pdf|
      options[:command] = :pdf
    end
 
    opts.on("--oneshot", "Single LaTeX compilation") do |oneshot|
      options[:command] = :oneshot
    end
 
    opts.on("--clean", "Clean the build artifacts") do |clean|
      options[:command] = :clean
    end
 
    opts.on("--open-pdf [HOW]", "Open the generated PDF with HOW)") do |how|
      options[:openpdf] = how
    end
 
    opts.on_tail("-h", "--help", "Show this message") do
      puts opts
      exit
    end
  end.parse!
 
  case options[:command]
 
  when :pdf
    build_pdf
    open_pdf(options[:openpdf]) if options[:openpdf]
 
  when :oneshot
    single_compilation
    open_pdf(options[:openpdf]) if options[:openpdf]
 
  when :clean
    clean_artifacts
 
  end  
 
end
 
run

Je ne garanti pas que le code soit parfait, alors n’hésitez pas à émettre des critiques constructives !

I just wanted to let the world know that I have just revoked my last 2 active GnuPG keys (see on the MIT GnuPG servers) as I haven’t used them for a while, so it was about time to revoke them.

In my very own case, I have rarely found a valuable usage of email signing and I don’t sign IzPack releases anymore. The terrible truth is that outside some sensible enterprise contexts nobody uses such techniques… except geeks. Maybe one day I’ll get another key if need be.

During the christmas break, I took an hour or so to play with Groovy and EJBs. EJB 3 are very easy to use (especially compared to what they used to be before that) so I decided to investigate how I could make them even simpler to use with Groovy.

Indeed, Groovy shares mostly the same meta-model as Java and you can easily mix Java and Groovy code in the same project (actually you can put .java and .groovy files side-by-side in your packages).

I opted for a simple hello-word style of project using Groovy 1.5 and GlassFish v2 ur1.

I started with a single HelloEJB.groovy file to host both the EJB remote interface and implementation as a stateless session bean:

package ejb
 
import javax.ejb.Remote
import javax.ejb.Stateless
 
@Remote
interface HelloRemote
{
    String hello()
}
 
@Stateless
class HelloEJB implements HelloRemote
{
    String hello()
    {
        return "Hello world!"
    }
}

The Groovy compiler takes care of generating 2 .class files (one for the interface and one for the class). Nice

Then I packaged this inside an EAR having groovy-all-1.5.jar so that GlassFish could make the Groovy runtime available to the EJB. Then I wrote this simple remote client to test it:

import javax.naming.InitialContext
 
def ctx = new InitialContext()
def ejb = ctx.lookup("ejb.HelloRemote")
 
println ejb.hello()

For this client to work, you need to put appserv-rt.jar from GlassFish in your classpath. Also, you will need to tweak a jndi.properties file at the root of your client classpath if you are not using the default GlassFish ports for your target domain.

I guess I can now save quite a lot of time using Groovy to implement EJBs

Disclaimer: I am dynamic-languages agnostic as I use Python, Ruby and Groovy for various things and I like them all. Really!

In a typical opensource fashion, I receive patches for IzPack.

I always review them carefuly, then I try to apply them on the latest source code tree. I am using either the BSD or the GNU implementation of patch.

For whatever reason, I can never apply the patches using these tools if they have been generated by Eclipse… The only way to merge is to launch Eclipse and apply the patch from there.

I haven’t yet managed to figure out why these patches cannot be applied using BSD or GNU patch. They really look like normal unified-style diff output…

Any idea?