TimShadel.com

After reading Phil Windley’s post about login.utah.gov, I wanted to check it out for myself. We’ve just finished a structure to users affiliated with the ASRS to register and login to future applications, and I was interested in the state-wide direction that Utah has taken.

In doing so, I stumbled across this site that is a pretty cool collection of the Utah state developers’ common practices, tools, and such. I’d like to keep watching it.

It’s been quite interesting to play with Ant 1.6. I’ve trying to figure out the best way to share macrodef snippets between projects, and I think I found my preferred way for now. There are two ways I see for sharing Ant macros:

1. Placing a common project in a well-known directory (typically up the directory hierarchy a bit), and then having all build files import that file
2. Using the new antlib to define the macros, and then bringing those definitions into the current build file

I think that the metaphor I’ll use is that common build files are a part of a separate, deployable project. This approach should support:

• One central place to change the shared macros
• Easy inclusion of local common macros and targets alongside third party macros and targets
• Sharing local macros with others external to this organization
• Consistent use of the shared macros in each project without requiring per-machine or per-login configuration

To meet those needs, I’ll do the following:

• Create a separated, versioned project for common build tasks, macros, etc. whose deliverable product is a JAR file
• From the project perspective, treat the common build JAR like any other Java library, and check the JAR into that project’s version control tree
• Use a standard directory in each project to hold all antlibs
• Invoke Ant using the new ant -lib [commonAntlibDir] [target] method
• Define namespaces at the beginning of each project file, using the xmlns:myTasks="antlib:my.domain.ant" syntax to automagically grab the shared task from the Ant classpath that includes the local project commonAntlibDir directory

One challenge is that always using ant -lib ... is bound to become tedious. Perhaps the local environment could be set to use this automatically, but that violates one of the goals. I’d prefer setting up the Ant libraries per-project rather than cluttering my local Ant installation, and hoping that everyone else has the needed libraries. This approach comes closest to doing that consistently than any other I’ve seen so far. We’ll have to see. YMMV.

I touched on O’Reilly’s publishing process in this post a little while ago, but I found an interesting note in James Duncan Davidson’s blog about his latest O’Reilly publishing experience. It will be interesting to watch how this type of work progresses.