Looking at merging in the HEAD options processing into alt-design, I took a look at XML-Commons CLI, which seems to tidy up options processing quite nicely.

However, I also took another look at both the Properties and Preferences APIs.

It seems to me that the current CLI options processing could be replaced by a set of command-line property definitions. This would be more in keeping with the assumptions of Java. One immediate problem is that any line-length restrictions would be sooner violated if we were using property definitions. Not being familiar with the requirements of application servers and embedded FOP, I can't comment on the implications in that environment.

If we do go that way, however, it brings up the issue of java.util.prefs again. It seems to me that a naive implementation of the API could use the existing config and userconfig files to provide the system and user persistent stores, at least for reading. java.util.prefs requires that the backing store be writable, however, and I don't know how this would fit in a server environment. (This requirement can probably be circumvented at run-time by assuming that the backing store becomes unavailable after the initial read: prefs is designed to be robust in the face of backing-store unavailability.)

We could address the JVM version issue by wrapping the java.util.prefs stuff in org.apache.fop.prefs or ...configuration classes which mimic .util.prefs by a thin wrapper around the latter classes, and providing for 1.3 compatible versions to be written. The availability of 1.4 could easily be tested at run-time, and the appropriate switch set for use in org.apache.fop.prefs, reducing the build complexity.

For now, I will just drop org.apache.commons.cli in and use it for options processing. What do folks think about these issues?

Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>

Reply via email to