Checking out JUnit 4 from the Source

During a meeting of senior developers where we kick around general development issues like whether to use Spring MVC or JSF going forward, a question came up from one of the developers about JUnit 4 and when it was supposed to be released. The motivation for this was he wanted to try using TestNG now.

A little light bulb went off in my head on the way to my oncologist’s appointment about an hour later. Maybe I can checkout the source to JUnit 4. After hunting through the Yahoo group for JUnit, I discovered a post that mentioned just getting the source for the JUnit 4 version on Sourceforge. Sadly enough I admit, I’ve never pulled down the CVS source before on Sourceforge. I actually never noticed the little CVS link in the projects. So with a little trial and error on the old command line below I got things checked out after a bit of fiddling:

cvs login
Logging in to
CVS password:

Just hit return here. I mistakenly tried a really old FTP habit of mine and stuck in an email address


. Of course it really needs a blank password so just hit return.

cvs login: CVSROOT may only specify a positive, non-zero, integer port (not `2401:').

cvs login: Perhaps you entered a relative pathname?

cvs login: warning: skipping invalid entry in password file at line 6

Not real sure why I got this message, something to do with some junk in my .cvspass file I’m sure. Anyway for a minute I throught it was failing but then I ran the next command and realized I was logged in to sourceforge.

cvs checkout -r Version4 junit

Success at last! I’ll check out JUnit 4 a bit tomorrow. This of course tweaks my interest to go ahead and pull down 0.6.3 of XPlanner from the Sourceforge as well, though after 0.6.1 and 0.6.2 failed me this is probably futile.

Reading the Spec

A few months back I held a Sprint Retrospective meeting after a fairly successful project release. We were going through the list of what went right and what went wrong when the issue of the Spec came up.

Arul: (slightly guiltly look) Well, we really should have written a better specification.  We just copied the it from Phase I, and it got signed just before we delivered to QA.

Ed: Did anyone read the spec?

John: I checked the HTML prototype a lot, but I didn't even look at the business rules document until after I had coded everything.

Michelle: It's always easier to work from the mockups.

Ed: So no one really used the spec document for anything, and maybe if we had put together a one page document on how we wanted to organize or project directory structure and naming conventions we would have gotten more out of the document.

Arul:  But we have to write a spec.

Ed: Really the spec is just a design document for us to come to a common understanding.  It sounds like we should just move the business rules elements into the HTML prototype since it's the only artifact anyone actually looks at.

Michelle: But the PM won't stand for that they'll crucify us.

Eventually I brought the team around to the idea that a traditional spec document wasn’t required for the project. As always old habits die hard, but we haven’t done any non-HTML spec documents for Phase III and it’s gone fine so far. If the HTML prototype is the one thing the developers find valuable, then the rest of the artifacts are just extra work. Some of the PMs are coming around to the idea as well one of them actually ran around a design document for signatures with one sentence in it, pretty agile.

$500 Barrier to IntelliJ Entry

Listening to JavaCast, a new podcast, I got to hear a bit of a rant by one of the hosts on he hated 30 day licenses like IntelliJ’s and that $500 was way too much of a barrier to entry. Based on my experiences I’d say there’s a bit of truth in the statement even if I think it’s way off base.

I’ve used at least 4 Java IDEs in addition to some text editors during my java programming career. I played around with JBuilder quite a few years ago, but never did much with it because the commercial versions were pretty expensive. After that I worked for a professional services shop that was an Oracle partner, so I used JDeveloper since we were trying to sell customers on the Oracle stack. As Eclipse began to build momentum, I picked it up along with a book since I found the interface pretty horrible to understand without it. When I started my current job the developers mentioned they used IntelliJ IDEA.

I’d of course heard of IntelliJ through it’s many raving fans at JavaRanch, the ServerSide and other sites. They all claimed that it was completely worth the cost, but I had never even tried it out because I didn’t need a new IDE and I couldn’t afford to pay for it.

Given the chance to actually use it, I downloaded it and ordered a license. The first thing I noticed was I was productive right away. I didn’t need to figure out perspectives or the plugin architecture. There was no weird forced directory setup for new projects and the CVS integration worked by turning on a single project setting, no need to even type in a password. The keyboard shortcuts were easy and straightforward. The refactoring features were very nice.

Now I’m not willing to give it up even though we’re in the process of adopting IBM’s toolset. Very much like the Mac OS itself it just works, and better yet it functions intuitively. I admit freely that Eclipse has pretty much the same feature set and certainly more options with all of the plugins available. Still, I won’t go back to it as my full time IDE after being exposed to the productiveness of IntelliJ.

The grain of truth is that a $500 price point did stop me from initially even evaluating it years ago. The difference was as a manager the 30 day trial and $500 price point made no difference, given how productive it was. All of my developers use IntelliJ now, and it has helped many of them as they worked through their first java projects. Many developers on another team use Eclipse and they find it fairly hard to use, since adjusting to things like perspectives can be painful.

So in closing I think IntelliJ is still solid Java IDE choice despite the price.

Pain with XPlanner

While XPlanner looked like a good solution for my problem, reality intruded when I got a 2 hour window to play around with it. It requires MySQL and a servlet container (Tomcat). In about 90 minutes on Friday I got it up and running.

Today I tried to setup a sample project or two with iterations, user stories and tasks. All of that seems to work fine. The problem would be that I can’t actually add team members and assign them to a project, a fairly significant problem. I went with blaming it on myself, until I came across a very similar bug. Apparently the fix is that after adding users you sometimes need to restart Tomcat. Unfortunately that didn’t work for me and the bug isn’t listed as resolved.

Next step was to drop back a version and try it. Unfortunately, the same problem, I can’t assign a person to a team. Next try is pulling the snapshot down from the Subversion repository. Or maybe I just fall back to the old excel spreadsheet.

Experimenting with XPlanner

Now that we’re starting to run multiple Scrum projects, I’m finding an excel spreadsheet not quite enough for organizing purposes. I looked at XPlanner and ScrumWiki today. Gave up on ScrumWiki pretty early since it’s Perl CGI based and doesn’t look like its had any active development for over a year. So that left XPlanner.

XPlanner is setup to work with MySQL, though you can use other databases since it implements its persistence layer with Hibernate. Installing MySQL on my work Windows laptop didn’t turn out to be too much of a chore, mostly wizard type install these days. No major hitches with XPlanner which is deployed as a WAR file. A minor item was that the current version of XPlanner isn’t compatible with Java 1.5 since it has the enum keyword in some of its packages. A quick addition of


to the


tags and the problem was solved.

Tomorrow hopefully I’ll get some time to play around with it and figure out if its worth the effort.