David Walend's Blog

Moving JDigraph

Spring Cleaning

Both sourceforge and java.net use CVS for source code control. Changing directory structures in CVS is a pain; in CVS, files really can't be moved around or renamed without loosing their history. CVS commands for directories feel like an afterthought. As a result, my directory structures in CVS projects tend to calcify into whatever I try first. So I took the opportunity to reorganize the source code tree, using ideas I've learned over the last few years.

Ant's Import Task

Changing the directory structure meant reworking the build.xml files, another chore I'd put off for half a decade. I considered shifting to Maven or Jython for the builds, but ultimately decided to stay with Ant. Maven gives a nice canned build, but it doesn't match my environments well (java.net, sourceforge, the day job). Jython would give a more powerful language, but leave behind entry level developers who can pick up Ant in a day. Ant 1.6's new import task really provides what I want.

For years, I've had almost identical build.xml files copied through many projects and subprojects. Ant lacked a nice way to pull functionality from one build file to another. (I know a few XML tricks, but those are more challenging than Jython.) JDigraph demonstrates that import was the main thing I was missing. Here's what a subproject's build file looks like now:

<project name="collection" default="test" basedir=".">

 <import file="../common/common-build.xml" />

<!-- set global properties for this build -->
 <target name="set-subproject" >  
  <property name="subproject" value="collection"/>
 </target>

</project>

Into java.net

After I rearranged all the code, checking it in to dev.java.net was easy. CVS on java.net is a little more trusting than on sourceforge; I only had to provide my password at the beginning of a session, instead of during every operation.

JavaDoc on java.net

The only real obstacle I hit was getting JavaDoc (and the rest of the web site) up on java.net. After a few rounds of email with the java.net support crew, I took their advice and put the whole web site into source code control, under the www/ top-level directory. (java.net's support is great. Thanks, Helen.) I can hear people I've worked with gasping in amazement; one of the big tenets I've held over the years was "never check in anything to source code control that comes from the build." My big concern is mechanical. If I have to check in all of the javadoc every time I do a release, then I have to somehow disconnect the old javadoc. CVS is not so good at removing whole directories. Tracking down all the obsolete javadoc files is even worse. So I created a directory under www/ called alpha-0-7-2/ (the name of the current version), and checked in all the source code there. Next release, I'll create a new directory for the javadoc; the build already puts in the correct link on the project's home page.

The CVS mailing list for JDigraph rewarded my cleverness with a fifteen megabyte CVS log.

The next problem was the javadoc didn't show in java.net's frames. Another email to java.net. Helen said to add "nonav" to the beginning of my links. ("nonav." "No navigation." I didn't get it for about two hours.) It worked like a charm.

Finding a Home

java.net is focused on about two dozen communities. That wasn't the case in June 2003 when I first reserved a spot for jdigraph. This summer when I finally moved JDigraph in, it was an orphan. At JavaOne, I spoke to a few people involved with edu-research at JECL, which seemed like a good fit. A few emails to Daniel Brookshier and Robert Stephenson closed the loop. I get the impression that a body of working, interesting, relevant code would get any project in the community (and an interesting idea would make the incubator).

What Could Be Better?

Helen knows I'm going to ask for Subversion. (She's not above encouraging me.) Wrangling the javadoc in CVS is labor. Switching from CVS to Subversion would answer most of the problem. I'd still have javadoc -- a product -- in source code control, but Subversion would make the job of swapping in a new version easy. Collabnet helps run java.net, and paid to have Subversion written. It seems like a natural move. The word from the support crew at java.net is that we'll have it someday, but it might be a while.

Comments

• website
  To a certain extent I can understand why java.net might want the website material under source control, because you can serve from several identical copies of the site.

  What I don't userstand is why the website of a project is not a single war file stored under a separate repository.

  The website of an open source project is its fundamental shop window. All the blogs and wikis just get people to look. I would have expected java.net to have a more integrated solution than this.
  

  Posted by: straun on August 31, 2004 at 06:25 AM

• Moving to java.net
  Good to hear about your experiences as I've been tempted to move some of my stuff over for a while now. It sounds fairly straightforward so perhaps I'll have another look.

  Posted by: simongbrown on August 31, 2004 at 06:33 AM

• website
  It'd be great to be able to just post .war files. Have you tried suggesting it to the java.net team? It probably won't be top priority, but will make their list. https://java-net.dev.java.net/feedback.html

  Dave

  Posted by: dwalend on August 31, 2004 at 06:45 PM

• Automated builds
  A choice of version control would be nice, as would a choice in bug tracking. What is java.net really needs, however, is automated builds. For the life of me, I can't understand why java.net balks at automated build support. There are a wealth of automated build tools for Java. Without automated builds (with unit tests etc...) the difference between it works and it works on my machine is all too common.

  If anybody could spare the server-side resources, you would think it would be Sun. They make giant uber-servers, after all.

  I have suggested this many times starting over a year ago. The responses that I've gotten indicate that automated builds are "beyond the mandate" of java.net.. If so, java.net needs a bigger mandate.

  Posted by: coxcu on September 01, 2004 at 08:15 AM

• Automated builds
  I can understand why java.net isn't up for automatic build support. They'd be letting us run fairly generic processes on their machines. That's opening a pretty big door. I wouldn't let just anyone do that. (Sourceforge feels differently.)

  It's a "nice to have," I think, and a difficult one to get right. Only the largest, busiest open source projects need this feature. Java builds are generally pretty quick, and generally run the same way on all platforms. I wouldn't let someone commit to one of my projects until well after they'd demonstrated that they can run the build. Do you really miss it that much?

  To frame it another way, would you rather have automated builds? cross-linked javadocs? Easy-to-digest information about downloads?

  Hope that helps,

  Dave

  Posted by: dwalend on September 01, 2004 at 12:24 PM

• Automated builds
  Yes, I really miss it that much.

  I would value it above all other missing functionality. Of course if I had an automated build, I would want coverage info and all of the other nice things generated from it. Java.net is free and I am greedy.

  All projects need automated builds. Small projects (and projects with few developers are the vast majority) need automated builds just as much as large projects, if not more. The fewer the developers, the longer a broken build will go undetected and/or unfixed.

  If you are a lone developer, an automated build allows you to test your program on another computer. Being competent and having working tests is much better than just being competent. If I fail to check a file in, the build and all the tests will still run on my machine, despite being broken in source control.

  Of course there is nothing keeping the conscientious developer from keeping an entirely separate directory structure for checking the project out of source control, building it, and running the tests after they do a check-in. I bet most developers don't do that.

  As for trusting people to run stuff on their servers--Java Isolates are long overdue, but Solaris has Zones and Linux has UML right now. Are the rumors true? Is java.net run on Windows?

  Posted by: coxcu on September 01, 2004 at 03:35 PM

This work is licensed under a Creative Commons License.