On Mon, Mar 7, 2011 at 8:01 PM, phil swenson <[email protected]> wrote:
> However given the nature of Java XML builds turning into multi-thousand > lines of un-debuggable XML hell, I think going with the flow will lead to > more pain than trail-blazing. The more I think about this, the more it seems to me that this "XML hell" thing is way overblown. Okay, XML is painful to read and not Turing complete, which is a bit annoying. But the tools are really top notch and completely pervasive, even if you're not using an IDE. I'm not even talking about catching trivial problems like forgetting to close a bracket but immediately catching bad enum values thanks to a DTD or an XSD. I was editing a plugin.xml file earlier today, and as soon as I made a mistake or a typo, my editor and outline views light up with squiggly red lines. The error is usually self explanatory but if it's not enough, I can immediately jump to the schema declaration, its DTD equivalent, the documentation and even if I want, all the occurrences of this element in the Eclipse code base. Needless to say, you never get stuck for very long with such support. Interestingly, promising solutions such as Gradle are behind XML in terms of validation, and they will probably not get there unless they start using enums and types for the entire language. Which brings up back full circle to the problems of using a statically typed, compiled language for configuration. No, really, I can't say that editing big XML files really bothers me much any more (and I say that as a big fan of YAML). -- Cédric -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
