I think xml for ant is ok for a simple build. Problem is if you are doing anything of significance, your simple build starts needing conditionals, variables, loops, and more complex constructs than procedures.
Then you start hacking ant to do this (sorta) and it becomes a nightmare. There is a reason we don't write our applications in XML. (As Casper says) XML a terrible programming language. If anything XML hell is under-blown, because I keep seeing the same horrible mistakes made everywhere I go. Unmaintainable, huge, un-debuggable, un-grokable, crazy slow builds. People jumping through manual hoops because automation via XML is too much of a PITA. Notice in the Ruby/Python/Groovy world everyone has tons of automation. They have auto-deployments to EC2, database migrations, tons of cool test/bdd frameworks, dev/test/prod environment setup, dynamic configurations, etc. They always are leading the way in automation. Yes, I know some of this exists in the Java world, but it's usually done long after it's invented in the dynamic lang world. 2011/3/7 Cédric Beust ♔ <[email protected]> > > > 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.
