This is a little rendering by yours truly from a current Sprint. Your average 3 year old could probably duplicate this scribbling, or as my daughter refers to it as “scribble-scrabble”. I just hope to add a tiny bit of whimsy to the project.

An old issue came up today when a developer dropped by my office and asked whether he should be putting the jars for his project in the project’s lib directory or loaded into the shared JBoss lib directory.

My default response was no, but I’ve gone ahead and thought about it a bit. Based on my experience as a consultant and building projects on servers I didn’t control I never wanted to worry about the app server and what was out there so I always included all the jars I needed. On most frameworks or tools I’ve looked at they were pretty much setup the same way. Going further back from my Perl CGI days long ago it always drove me crazy that many Perl apps required a ton of dependent libraries that you always had to dig up on CPAN. So inherently I like the idea that I have every library I need stored with the project.

The developer made the argument that it was better to reuse the jars in the shared server library. And he was concerned about deploying large WAR files. The large WAR files is pretty much a non-issue, given the requirements most places have and the overkill hardware this never seems to be a problem. I also don’t like classloader issues when they crop up and encapsulating everything pretty much takes care of that. Still the reuse argument is pretty basic.

Of course this means if you have a dozen projects deployed and you decide to upgrade some version of a commons jar you may have to clean up 12 different projects even though many of them are probably never going to need to be touched otherwise. And in our environment some of our applications will deploy to JBoss and some to Websphere which seem to handle class loading issues differently. According to IBM wisdom apparently they suggest keeping all the libraries in the EAR or WAR. We’ve heard the same thing from some of their consultants.

So I think we’ll still encapsulate all the jars with the project, but I’ll probably run the idea by some of my senior developers. Never good to assume you know the best way of doing things.

After getting XPlanner running late last night on my iBook, I got a chance to try it on my PC at work late this afternoon. After dropping back to MySQL 4.1 instead of MySQL 5.0 the install went pretty cleanly and all of a sudden I could add users to a project and assign them to tasks. Of course when adding new users to get them to show up you still need to recycle your app server, Tomcat 5.5 in my case.

I spent some time going through the interface tonight. As per usual with an open source project there is fairly minimal documentation, but you can flail your way through the interface and figure it out. For Scrum one hint I did find is to setup a Product Backlog Iteration far in the future, and then move them into Sprints as they get lined up. The time tracking is more sophisticated then I need and I probably won’t use the tool to have the developers individually track their time. One funny think is that none of the charts appear. Apparently they fire off and run on some sort of overnight schedule. Considering mine’s on a laptop I’m not sure I’ll see the charts tomorrow.

Right now I think it’s going to meet my needs well enough for a basic tracking tool, and it saves me from Excel hell.

I got really excited that I was finally going to be able to install XPlanner on my XP laptop for work by pulling down the latest source with subversion, 0.7b2. Unfortunately the results have been eerily similar to the first attempt. Essentially I can never add a person to a project, making it well nigh useless to use.

So back to my trusty Mac OS X iBook. After about 90 minutes I got XPlanner 0.6.2 up and running and learned that MySQL has a very nice GUI installer for the Mac these days. The only major change I had to make was to change localhost to 127.0.0.1 in xplanner.properties:

It still feels a bit clunky, but I think it’s usable now that I can add people to tasks. Even though it’s late I feel a lot better getting over the frustrating hurdle.

One of the developers on XPlanner, Jacques Morel, dropped me a comment on my post about my Pain with XPlanner post:

0.7 is very close (within a month) and has this problem solved.

You can build it right now from subversion. It is rather stable (we release it every 2 weeks internally). I am scheduled to put out a beta anytime now.

So I’m a sucker for personal contact and open source tools, and I don’t really like spending much time in Excel. So it’s on my Backpack todo list for tomorrow, so assuming some fires don’t erupt at work I should be able to pull it down and try again. And of course this will force me to pull down a Windows subversion client at work, probably Tortoise SVN.