The Goldfish Chronicles

Long before I started dumping code on Commons, I had my GenJava libraries. Originally these lived at www.generationjava.com, then they moved to osjava.org. I signified a util class with a W [it was before we had XxxUtils as such a common pattern, and yes it seems silly now]. It stood for Wrapper. Which meant something like Helper, but originally actually wrapped the underlying Java class. Its first few methods were probably written in early 2000, so 8 years of life.

Over the last couple of nights, I’ve been deprecating and removing code that has moved or parallel evolved at Commons. Tonight the StringW class, which originally made up a large amount of Commons Lang’s StringUtils reached the point where there was nothing of value left in it:

r2639

The aim is to deprecate gj-core as either being found elsewhere or not being worth the effort of maintaining.

Resurrecting this from the data for the Commons blog.

It’s always a pain to be putting in tracing statements (aka System.out.println) and find that the object’s data is hidden away in private attributes. One option is to break out the debugger, another (security manager willing) is to use the org.apache.commons.lang.builder.ToStringBuilder to output the Object in full. Here’s the very, very simple line of code to get this done:

System.out.println("TASK: " + ToStringBuilder.reflectionToString(task));

After what seems like forever, Commons CLI 1.1 is released; bugfixes and some minor improvements. In the end it was Brian Egge who pulled up his sleeves and finished off the last issues, so much thanks to Brian for making a release happen.

By the way, here’s the latest incarnation of the Commons JIRA report: http://people.apache.org/~bayard/jira-report-for-commons.html. It’s nice to be able to view it in one go rather than as many individual projects.

Commons hasn’t grown much recently - much is actively maintained but we haven’t added a lot of new things (SCXML and VFS the notable exceptions). I happened to be writing up a status for all of Commons and the number of components surprised me.

• 32 Released
• 12 Sandbox
• 38 Dormant
• Which equals 82 Total

I mentioned a while back that I wanted to make a report that gets sent to JIRA for Commons. It’s been done for a while, though it’s not being sent to the list yet. Here’s an example: http://people.apache.org/~bayard/jira-report-for-commons.txt.

It uses the trunk of Swizzle JIRA Report and custom vm file. The idea, as I mentioned before, is that it should give us a feel for projects that need to be considering releases, and issues that need attention. The logic is:

for each Commons JIRA project
  for each version
    show completed-issues-count and issues-count (how close to a release we are)
    for each issue with >= 2 votes
      show issue
  for Unversioned issues
    show issue

I like it, but I suspect it is still too noisy to have value.

I should have said this a few days ago - Congratulations to Martin van den Bemt on taking over as Jakarta Chair (or V.P., Apache Jakarta for the official records and the IRS). Martin’s been around at Jakarta for ages and will do a great job.

I’ve been saying “I need to start a blog on Jakarta Commons things” for ages, so this weekend I finally got around to doing so. It’s at http://www.featheredblogs.org/blogs/page/commoners and hopefully I can lure some of other Commons coders into doing some authoring.

I’ve got three categories so far. The first is pretty simple, “Releases”, in which I pretty much just cut and paste the announcement from the project. It shouldn’t be a huge surprise to anyone though as I’ve got a bookmark list in the navbar displaying the projects who are currently working on release candidates.

The second category is “In the Sandbox”, the idea here is to interview people bringing new things into the sandbox. Things tend to hide away in the sandbox, so I’ve a few canned questions for when the project’s website is up and available.

The third category is “Tips”. It’s as simple as it sounds. Happy, useful little tips on Jakarta Commons. I used to write such things for CNet/Techrepublic, so it’ll be fun to write them again (and not have a painful deadline).

One last thing to mention is the Triage link. It’s not cron’d yet, but the purpose is to pull together the issues in the Commons project that don’t have a fix version yet and display them in a single report. By remembering the last report, a changes email can be sent to commons-dev too.

Stephen Colebourne blogs about Commons Collections and JDK 5.0 Generics - should Collections have a new release which embraces generics.

One of the replies is that all Commons components should move to Java 5 - to which I give a very strong +1. If people need releases and branches for old versions to be maintained, then it’s pretty easy to make bugfix releases off of a branch, but we need to keep things interesting to maintain community involvement. Maintaining Java 1.2 code is quite irritating.

Played with multidoc a bit again tonight. Taking Antony’s modifications and bending them to my needs: http://people.apache.org/~bayard/multidoc-jnr/.

There are 104 different javadocs there, nicely arranged by artifact and version - with jardiff reports for each pair of consecutive javadocs.