Although the task of starting and stopping a given Mozilla Applications is taken on by all Mozilla tools there is no shared code for accomplishing this task. Historically most Mozilla tools have just been part of the main repository and act as “scripts” instead of more independent Python libraries and/or Extensions. This meant that shared code could only really be accomplished through cut and paste.

The task of just starting and stopping the Mozilla Applications is harder than it would seem, particularly when it comes to stopping. There’s also a bunch of other things you wanna do to Mozilla Applications when you’re launching them; set preferences, install plugins, build new clean profiles and use them, add command line arguments to the launch, etc.

mozrunner is a Python library that is independent of any particular Mozilla application source repository and is hosted at http://code.google.com/p/mozrunner . The library takes on the task of starting, configuring and stopping Mozilla Applications (only tested against Firefox right now but it should work with Thunderbird, Songbird, etc. and patches are welcome). We used this library when developing the new Gristmill suite of test automation tools and it’s been wonderful to work with.

The current documentation is over on the google code wiki; http://code.google.com/p/mozrunner/wiki/UsingMozRunner , there is a lot more that you can do with mozrunner that still isn’t up in the documentation and I plan on just adding it as people ask me how to do things.

If you have Python and setuptools installed you can just install it via easy_install.

$ easy_install mozrunner

It should find your local Firefox install by default, so just running mozrunner from the command line should launch Firefox. You can also check out the –help for some simple configuration and testing of the launcher script.

$ mozrunner --help

But of course, you shouldn’t be executing the script from within Python, and you’ll find some information in the docs about how to simply import the mozrunner Python library and embed the launching and configuration in to your tool.

We decided a while ago that it would be best to move the windmill project off of OSAF’s infrastructure.

The decision was much easier to come to than the actual execution of the move. I had assumed that the difficult things to migrate would be Trac and that the subversion migration would go by fairly smoothly, I was mistaken. The Trac migration turned out to be much easier than expected, and the subversion migration took hours of fighting with the new server (the culprit ended up being a /usr/local/bin/svnserve hiding out that svn+ssh liked to use instead of /usr/bin/svnserve causing version mismatch problems).

The new hosting is distributed between a personal server of mine ( Trac, subversion, Tutorial) and some hosting that Adam Christian has setup (www.getwindmill.com w/ new Blog) with all the email lists moving to Google Groups.

At the end of the day we have a whole lot of great new infrastructure. The new blog is a great, it’s a Wordpress install with a lot more features than we previously had and new video tutorials. The svn checkin emails are nicer because it’s a newer package. Google Groups is much nicer than MailMan. The subversion server is significantly newer and on the same box as the Trac install which cleaned up the one revision number mismatch we previously had do to using an svk mirror. And we have Google Analytics setup for all the new sites which is going to keep us abreast of articles and events that send new people to the project.

This is getting us all even more excited about the upcoming windmill work and Adam is getting ready to go out promoting windmill more aggressively than it’s ever been pushed before.