Software is too expensive to build cheaply…

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…)
(more…)

Tags: selenium

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.

Tags: bug, issuetracking, maven, sucks

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.
(more…)

Tags: java osgi tutorial

I’m going to be spending some time over the next couple of weeks learning about OSGi – there is an application at work that we want to try and make more modular. In particular, we’d like to be able to share the back tier with more front end clients. The more conventional modularisation techniques, such as EJBs, have been tried and didn’t work fairly well. Simply creating more deployments is prohibitive, due to hardward And before someone asks “why not just stick a web service on it and share that way” – some of the front end clients will be those web services. To cut a long story short, one of the options we want to check out is OSGi.

The only problem is that there isn’t much in the way written up on the web about writing OSGi components – at least not without invoking magic tools (e.g. Maven plugins) that don’t work on any version of any tool developed six months later. Which is odd, because OSGi, as a spec, doesn’t look that hard to write too. So, I thought I’d write up a series describing the initial investigative spikes, starting as close to the metal as possible and working up.
(more…)

Tags: osgi java glassfish

I saw an an article on Seth Godin’s blog about positive thinking. Godin makes the valid point that people who think positively tend to succeed more, in part because their confidence means they don’t second-guess themselves. You can easily waste a lot of energy debating what to do.

A point that Seth didn’t cover is that positive thinking means it’s more likely you will attempt something new: if you feel you can accomplish a task, you’re more likely to try. Sometimes, when you try something new, you will succeed. Other times you will fail. When you fail, there’s a chance you will learn – and learning makes it easier to succeed next time.

One of the key take aways of agile development for me is “experiment, and fail early”. Fail early, fail often, fail cheaply. And learn every time.

from Martin Fowler: Software and Obama’s Victory. I like the last org model shown; it would be very interesting to work in a company structured in such a fashion, with middle management acting as guides & facilitators, instead of intermediates, filters and superiors.

Tags: fowler, martin fowler, obama, org structures

Lusting over the Atlassian Connector’s support for Bamboo made me decide to check out what support there was for Hudson in Eclipse. So I checked out the Hudson Eclipse Plugin. My thoughts: not bad, but not great – a lot of potential is there, though.

(more…)

Tags: eclipse, hudson

In two words: pretty neat.

(more…)

I’ve been having a problem installing the Atlassian Connector for Eclipse (which gives integration to a bunch of Atlassian and non-Atlassian tools – mostly I’m after Fisheye and JIRA). The installation constantly failed for me on this error:

Cannot complete the install because one or more required items could not be found.
Software being installed: Atlassian Connector for Eclipse (recommended) 1.1.0.v20090624 (com.atlassian.connector.eclipse.feature.group 1.1.0.v20090624)
Missing requirement: Atlassian Connector for Eclipse (recommended) 1.1.0.v20090624 (com.atlassian.connector.eclipse.feature.group 1.1.0.v20090624) requires ‘org.eclipse.mylyn.jira_feature.feature.group [3.2.0.I20090529,3.3.0)' but it could not be found

Today I found this issue in Atlassian's issue system: [#PLE-393] Installation error – Atlassian Projects. What it comes down to is that one of the update sites shipped with Eclipse is disabled in some of the distros (the JavaEE one, in my case).

The issue has the instructions, but for anyone too lazy to follow the link:

The problem seems to be that the Mylyn update sites (which has JIRA) is not enabled in your copies of Eclipse. There is a bug in Eclipse that these sites may not be automatically enabled even though we specify that we require them for installation. To enable this site:

1. open Help > Software Updates…
2. switch to the “Available Software” tab
3. click on “Manage Sites…”
4. look for either the Mylyn Extras update site or a url that looks like: http://download.eclipse.org/tools/mylyn/update/extras and check make sure that it is checked
5. look for either the Mylyn For Eclipse 3.4 update site or a url that looks like: http://download.eclipse.org/tools/mylyn/update/e3.4 and make sure that it is checked
6. try to install the Atlassian Eclipse Connector again

And with that, I get my JIRA integraton to Mylyn working again! Joy and happiness abounds.

Tags: eclipse atlassian

In my previous rant, I bitched about the eclipse:eclipse plugin. I got a fair amount of feedback suggesting I look at the M2Eclipse IDE plugin instead. This plugs directly into Eclipse, introducing in-IDE maven support.

Well, I’ve looked at the M2Eclipse plugin, and decided it’s still not suitable for my personal working style.

For anyone interested, here’s a short list of reasons. Note that I haven’t actually _tried_ the plugin – I’m just going off their FAQ.

• No real support for separate output folder. I can’t stand having my IDE and my build tools compile to the same folders. With Eclipse, in particular, it’s a different compiler! Compiling to the same folders results in contention, and I don’t do it. The M2Eclipse plugin used to support this as an option, but they took it away in version 0.94. This isn’t hard folks – let Maven compile to one place, and Eclipse compile to the other, and never-the-twain-shall-meet. Strike one.
• It uses the Maven Embedder. The Maven Embedder is not Maven. It’s a somewhat bastardised version of an unreleased-even-as-beta version of Maven. It doesn’t even use the Maven Embedder that came with 2.1 – instead, it uses a “Embedder component build in May 2008 ” which is “somewhat outdated”. This means it’s got different bugs in it from the command-line Maven. I don’t need to chase down two sources of maven bugs. Strike two. (Okay, you can apparently tell it to use an installed Maven elsewhere – wonder what functionality _that_ breaks; we currently use Maven 2.0.9 because both Maven 2.1 and Maven 2.0.10 broke stuff)
• It wants to use the JDK associated with the JRE that launched Eclipse. Well, I use a Mac. Due to SWT issues, Eclipse on the Mac has to run under Java 1.5 (though that may change with the upcoming release). But I compile against Java 6, and that what I want to run Maven under. Strike three, and you’re out.

Look, it may be a great plugin. Obviously people like it. But it doesn’t suit me.

Tags: maven eclipse