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.

I picked up and poignant tidbit from <a href=”http://joelonsoftware.com>Joel Spolsky</a> after listening to a recent podcast on IT Conversations. Joel was talking about the big technical book boom of the dotcom era and that publishers noticed a trend that often the bestsellers in a topic area were determined by book with the thickest spine. Thus publishers began delivering more and more books that were breaking the 1000+ page barrier. Readers apparently having no better criteria to judge by were apparently buying the thickest book assuming it covered the material in more depth.

From a personal standard, this is almost the opposite of my approach. From my standpoint I have a limited time as a manager to delve into new areas. Thus I want to be able to dive into a topic quickly and get a good understanding without being buried in example code which often doesn’t even compile. I detest most of the 2″+ stuff with 8 authors most of which is a waste of bandwidth. And I do appreciate these days that every web technology book doesn’t begin with two chapters on the history of CGI to today anymore or explain the great issues with the stateless web or even better the huge difference between HTTP Post and Get.

So lately I find myself really enjoying the Pragmatic Programmer Series or some of the O’Reilly’s Developer Notebooks, and I actually read all the way through them. I still buy plenty of thick books, but they’re almost always more reference types like JUnit Recipes or J2EE Web Services. I never read all the way through them.

The only recent contradiction of this recently is that I picked up Holub on Patterns after attending a talk of his at SD West 2005. I read straight through the first hundred pages or so of his critiques of Java versus true OO, and then blew off the rest of the book which was basically some elaborate code examples of many of the GoF Patterns.