July 11, 2003

Make your process exclusively externally configurable

This morning I built the Maven beta-10 snapshot – it’s supposed to support inherited properties which will be very useful for my setup. But then my build stopped working, and I noticed from the error messages that it was now using ~/.maven/ for a local repository. WTF? Did I miss that on the massive output whizzing by during the seven and a half minute build?

Maybe, but it's probably just a change in some properties file picked up by the startup script, right? Or even, god forbid, a change in the startup script itself. So I go through the maven.bat file and see reference to using the home directory if MAVEN_LOCAL_HOME is defined. Is it set? Nope. So what's going on?

Remembering something from the mailing list I did a jar -tvf on $MAVEN_HOME/lib/maven.jar to find properties files therein. There were three, and the defaults.properties had a stink about it. So I unpacked the jar and had a peek inside. Sure enough the first setting was:

maven.home.local = ${user.home}/.maven

Gah! And AFAIK I have no way to override this by changing a file outside the application libraries. So now I have to change the properties file, JAR it back up to the library and replace the old library with my new one. That's not difficult, but what happens when I need to replicate this setup for new developers? And even once it's setup properly, when someone accidentally hoses their install they'll have to come to me (or read the wiki, which everyone still forgets to do) to fix it.

Maybe there's something I'm missing, but I can't see any reason for these files to be embedded in the library. Put them in the bin/ directory next to the startup script so you have an idea of how to modify the script's behavior, and have the option of sourcing them from a ~/.maven/ directory as well.

Next: An indication of cosmetics insanity
Previous: Silly, silly