You are currently browsing the Philipp Meier's weblog blog archives for September, 2004copyright


Use entities to manage dependency versions in maven

Just stumbled over EnsureProjectConsistencyWithEntities
in the maven wiki.

This really helps if you use the multiproject plugin. The proposed usage of XML entities provides a simple way to manage dependency versions in one central file.


Integrate the SVM CVS/SVN Revision Frontend in your gnome desktop environment

I just discovered SCM, a simple Revision-Viewer Frontend to SVN, CVS and Bitkeeper and I integrated it in my gnome desktop. Follow this steps:

1. Download SCM and the salma-hayek library. Extract them somewhere

2. Edit scmtool to represent the location of the salma-hayek library.

3. Edit scmtool to use GTK-L&F by default:

add the following after the line “fi”

if [ "`uname`" == "Linux" ]

This step is optional, though.

4. Add a starter for revisiontool to your desktop

5. Drag a scm/csv/bitkeeper-managed file onto the starter an have fun!

Escape the XML Configuration Hell

In “The XML Configuration HellMatthieu Riou complains about using XML as a configuration file format. A clear disadvantage lies in XML’s verbosenes, although the original author forgets to mention it advantages: splitting of files using entities (a feature seldom used in practice), formal declaration and validation of structure with DTD and Schema, standard parsing utilities, XML support in most editors and so on.

Nevertheless I, personally, hate to write XML configuration files. Take Jetty [] as an example. Jetty is a java servlet engine and webserver that uses XML as it’s configuration format. Quickly commenting out a line to disable debug logging — a common task for any sysadmin — is just not possible because of the nature of XML. Any “linebased” file format has a clear advantage in this respect.

On the other side, the idea behind jetty’s xml configuration is nice, basically it’s a kind of xml-java scripting language. It provides a set of tags to instanciate objects (HTTPListeners, WebContext, Logger), to set properties on them and so on. It should be rather simple to throw the XML stuff away and replace it with a groovy configuration builder.

A short note to a comment from Gavin on the referenced article who claims that groovy would be much more verbose than a XML configuration: I doubt that this is true because of groovy’s NodeBuilder feature. This makes the following possible, which is not bigger then a comparable xml configuration:

server.config {
  log() {
    level(default: 'info')
    level(session: 'debug')

  webapps(basedir: '/usr/share/webapps/', hotredeploy: false) {
    webapp(path: '/opt/webapps/confluence.war')


Use XStream, XSLT and XSL:FO to generate PDF

I recently digged into XStream and liked it immediatly. But I had no use for it since now. As the developer of webworks XSLT support I built a Bean-to-XML mapping layer before bad currently I have not the time to mantain it actively. For my current project I needed a way to print some reports in a swing application. Remembering Apache FOP I thought of using my webwork xml framework to generate some XSL:FO. However, I wanted to give XStream a change and it was quite successful.

The basic setup was using XStream to serialize my print content (e.g. a InvoiceBean) to XML and mangle it with a nicely crafted XSLT stylesheet who’s output would be rendered to PDF by FOP. The were some minor hurdles.

Repeated references to the same instance which XStream converts into XPath references are hard to impossible to render with XSLT. This can easily changed by setting an options in xstream but will give you some trouble in case of circular references. The is an extension in xalan to evaluta XPath references in XSLT stylesheet at runtime but I did not manage to get them werk.

The second problem was a little tougher. Because XStream acts as a serializing framework it serializes class fields, not properties. This subtle difference comes into play in case of derived properties like

public String getFullName() {
    return getFirstName() + " " + getLastName();

However I managed to use XStream with a custom BeanReflectionProvider which uses the Introspector api to determine the fields to “serialize”.

At a glance this gives you a nice printing franmework in Java based on major standards.