I’m currently developing a play app that, according to the corporate policy, needs to be built by a Bamboo server and then deployed. Sounds easy, right?


The Bamboo server is running on Solaris, play requires python and getting python to build on Solaris does not seem to be a trivial issue. The sysadmin built and installed python 2.5.2 (the version that comes with play) and python 2.5.5 and neither of them worked due _socket missing or a few other things. This, understandably, did not lead to good feelings towards me regarding my advocation of the play framework. It’s possible this was caused by user error – certainly, when I built python 2.5.2 on opensolaris and tested it, it worked fine. However, this is what we had and this is what had to be used.

Or…was it?

The Jython project has been around for a few years now, and presented an escape hatch from this situation. Because of how the build process works, anything that is needed during the build (apart from a few base essentials like Java) must be downloaded from a private maven repository, temporarily installed and used, then deleted – all in a Maven script. Using the Jython installer, I created a standalone jar and put it into the repository; to match the play-shipped python version, I wanted to use 2.5.2 and this is not yet available via the standard Maven repositories. I updated the POM to use the exec plugin to start Jython and use it to run the play python script.

>> webbrowser.py not found


I unjarred Jython, then got hacky – it was time to create Jlaython. I plundered the play installation, copying ${PLAY_HOME/python/Lib/webbrowser.py, ${PLAY_HOME/python/Lib/__init__.py and the contents of ${PLAY_HOME/framework/pym into jython-unjarred/Lib. I then jarred this up again, using the existing manifest file to ensure the Main-Class attribute was present.

jar cvfm jlaython.jar META-INF/MANIFEST.MF *

I then tried to use this to run play.

java -jar jlaython.jar $PLAY_HOME/play war myapp -o /tmp/myapp --zip

The result – it worked. Which is to say, it worked on Solaris. I didn’t test it on Linux, because frankly I’m working my arse off at the moment and that would have been a luxury. I did test it on Windows, which is the development platform of choice at my current contract and of course it failed miserably. Luckily, a) it doesn’t need to be built on Windows via Maven, and b) you can just use the exec plugin to invoke cmd /C play war directly due to python for windows shipping with play.

Lessons learned:
– write once, run anywhere is bullshit – learned this a long time ago, but it’s always nice to have a reminder.
– if you can’t develop on the OS you’re deploying to, at least have access to a box with that OS – see point 1.
– elegant solutions can often have inelegant failures – play’s use of python works well in the majority of cases, but when it fails, it fails all the way.
– inelegant problems can often have workable, crude solutions – updating the jython jar to include the play scripts is, let’s be honest, somewhat of a brute force approach. But, when the standard solution fails and you need to get creative because time is running out, a working solution beats an elegant solution.

Leave a Reply

Your email address will not be published. Required fields are marked *