In any battle between the source code and the documentation, the documentation always loses. Note that this is not the same thing as the source code winning.
In the last segment, I managed to get JBehave reporting under Maven using a pre-canned example. This time, I want to tackle the other extreme – I want to develop a single story in JBehave and see what’s the bare minimum it takes to get it running, inside an IDE (in my case, Eclipse)/
JBehave comes with some very comprehensive examples, so I thought I’d start there to see if I could get one of them building – and reporting – under Maven. The example I chose was the ‘trader‘ example, which you can see at github.
A couple of years ago, I got the ‘specification-by-example’ bug. I was playing with this new project called Cucumber, and was really enjoying the idea of specifying examples in an English-like syntax that testers and BAs could supposedly read. (I say supposedly, because it never really took on at my previous place-of-employment. Which was a shame). Nonetheless, I enjoyed it, and advocated it when and where I could. Heck, if nothing else, it was an excuse to write support code in Ruby as a break from the Java stuff.
There are three basic approaches to writing software that I know of. The first is always strive for technical excellence. This is great if you can do it – I’ve never worked in a place where technical excellence was always priority #1 with no compromise. If that’s you, then you probably don’t need to read this.
The second way is throw code around and hope it works – this is far too common. You look at the problem in front of you, and you grab a solution that’s good enough for now, doesn’t blow the budget (time and money) too badly, and leave the mess to be cleaned up (or worked around) later. Industry wide, this is the norm – a consequence of always focusing on the short term.
The third is a pragmatic compromise – try to make it as good as possible, while recognising that parts of the system will be, well, shit. That’s what I want to talk about here.
Very handy way of creating an OSGI bundle out of an otherwise normal Maven project.
Having converted the customer-facing pages of Wotif.com from a Freemarker/WebWork/EJB stack to a Grails/Spring3 stack earlier this year, I’m now officially a huge Grails fan. In setting up a new dev box, I wanted to install it – but who wants to install a download, huh? I wanted to build it from source (you can tell I’m a former Gentoo user!). Here’s what I did.
I love Selenium. It’s a great tool, that does a damn fine job. But one thing I’ve been wanting to do for a while is to get it to use a different DNS server to the box it’s running on.
Here’s how you do it:
java -Dsun.net.spi.nameservice.provider.1=dns,sun -Dsun.net.spi.nameservice.nameservers= -jar selenium-server.jar
(Caveat: may not work on non-Sun JVMs. Does work on OSX, though…)
Continue reading “Selenium Trick: Using a different DNS”
Some months ago, I wrote about how the Maven Eclipse Plugin 2.7 release didn’t fix a bug introduced in 2.6
Well, neither does the newly released 2.8 version.
Guys, I know you didn’t hear me earlier, but for pity’s sake – DO NOT RELEASE SOFTWARE while you still have critical bugs open. If you don’t want to fix the bugs, edit the issue so it’s no longer bloody marked as critical.
Covers turning the simple web app from the first installment into a simple web app using an OSGi Bundle.
In the first installment, I outlined a simple web application. In this post, I will be turning that application into two parts – an OSGi bundle, with a client web app.
Continue reading “OSGi Diaries – Creating A Bundle”