Did you read the article behind the post?
When there were 10 or 20 keys in the build file, this wasn't so bad. But as projects grew in complexity, editing these files became an exercise in managing the visual noise created by all the repeated initial parts of property keys. It was clear to me that using properties for the build file syntax just wasn't sustainable in the long term.
James is not talking about XML being bad for configuration, he talks in general about it not being the right technology to be used as a backend for a scripting langauge which as I quote:
In retrospect, and many years later, XML probably wasn't as good a choice as it seemed at the time. I have now seen build files that are hundreds, and even thousands, of lines long and, at those sizes, it turns out that XML isn't quite as friendly a format to edit as I had hoped for. As well, when you mix XML and the interesting reflection based internals of Ant that provide easy extensibility with your own tasks, you end up with an environment which gives you quite a bit of power and flexibility of a scripting language—but with a whole lot of headache in trying to express that flexibility with angle brackets.
Size is a concern, but than multiple build files help resolve that and structure your project build process much better. I mean, Java class with thousands lines of code is as unreadable as an XML file or a property File or even a Script-based alternative of such size. Verbosity is a tradeoff of readability and again multiple build files help.
The property file format would have been even worse, since it would be flat and a given developer would have no clue about the dependencies and hierarchies of the project build flow.
James points out that he should have:
From what the article says, the Ant and it's original intention was abused turning into a scripting environment rather than project build structure and scripting was not an intended feature.
Now, I never intended for the file format to become a scripting language—after all, my original view of Ant was that there was a declaration of some properties that described the project and that the tasks written in Java performed all the logic. The current maintainers of Ant generally share the same feelings. But when I fused XML and task reflection in Ant, I put together something that is 70-80% of a scripting environment. I just didn't recognize it at the time. To deny that people will use it as a scripting language is equivalent to asking them to pretend that sugar isn't sweet.
So, why blame any technology, in this case XML, because of an obvious developer's abuse? Isn't it really up to the developer or architect to decide what technology is applicable and where?
I think it is and therefore there is nothing wrong with XML, it being in Ant or anywhere where APPLICABLE, but the developer's abuse will always be there and we would always have people who would complain how a given technology fails to work outside of it's defined paradigm! Duh! No technology is a panacea for every little problem one may have. Being a developer is having an ability to see how to use the healthy blend of available technologies effectively to deliver stable, scalable and usable applications.
BTW article does not suggest any concrete alternative, just a variety of possible choices. It is interesting how XML gets blamed all the time for not doing that and that and God knows what, but nobody, not now nor ever was able to present a decent alternative for doing all of those things everybody complain about. I have not seen a single concrete example, just bashing, bashing and more bashing...
Artem D. Yegorovhttp://www.activexml.org