Discussions

News: Groovy and BSH to kill XML :)

  1. Groovy and BSH to kill XML :) (27 messages)

    As if by magic, there were two entries on using scripting languages instead of XML. One shows how to use Groovy to configure Spring, and the other shows how to use BeanShell instead of Ant. Of course it could have been the other way around too (Groovy for Ant is popular for example).

    Groovy killed the XML file?
    The proliferation of XML files for configuration bugs me. All of the XML configuration mechanisms I have looked at are used to create and wire application objects together at launch time. I'm the lucky one who gets to write and maintain these files. Framework developers have to write and maintain thousands of lines of code for processing XML files, and creating objects based upon them. There must be a way to achieve the same end which lets me forget about XML and absolves the framework developer of the need to maintain so much XML parsing code.

    I started looking at Groovy a few weeks ago and liked what I saw. I worked with Objective-C before I picked up Java so it's nice to see some of the more dynamic features I was used to creeping into a JVM compatible language, even if it is a scripting language.

    So, I thought, can I use Groovy scripts instead of XML configuration files to wire my application objects together? As a proof of concept I opted for scripting a Spring configuration. Spring is a (buzzword)"lightweight container" where JavaBeans are declared as named items in an XML configuration file and can be wired together to construct application services.
    Read Groovy killed the XML file?

    ant bsh configuration
    in my quest to rid the world of xml configurations i decided it was high time to explore the possibility of using bsh to configure ant projects. before i begin however i wanted to comment on some findings i have made. i am certain someone will mention james' article that describes how to script ant configurations with groovy -- so i wanted to state upfront that i do not like this approach and more specifically i do not like groovy. there i said it. secondly the ant code is a disaster. obviously not many people actually look at open source code or ant would have died a quick painless death. however i digress, after several hours i was able to put together code and an example of what is involved in scripting ant builds with bsh.

    my exploration lead me to discover that fortunately ant does have a hook that allows for the ability to specify a helper which allows for a custom parse method. after digging around the documentation i was able to find that the org.apache.tools.ant.ProjectHelper can be set to specify a custom BshProjectHelper. as stated in the ProjectHelper class, it must be extended and implement a parse(Project, Object) method. that file is listed next.
    Read ant bsh configuration

    Threaded Messages (27)

  2. Deja Vue....[ Go to top ]

    Anyone remember TCL? Anyone remembers what is actually meant? Tool Control Language!

    Well, it seems to me we are there now with Java. So, as a wild guess, languages like Groovy will more and more move into the mainstream, than they will get scrapped for the next cool thing.

    Hey, I may go and pick up that COBOL book, who knows.
  3. I'll agree that some XML configurations are a real bear to work with, but I'm curious as to why people are so bothered over Spring's or Ant's XML? A well formatted Spring configuration file is easy to read, and does a good job of explaining how an application is put together. The other nice thing about XML is that so many tools out there (editors) can understand and work with it - whereas groovy or beanshell syntax support is a little harder to come by. Yes, the industry went overboard on XML, and many people want to backlash against it, but it still has a place. Maybe configuration isn't always that place (J2EE / EJB XML configuration truly is a bear), but the example groovy based Spring configuration given in the article just doesn't do as much for me as the XML configuration.
  4. I agree wholeheartedly on the tools. I believe they should abstract the XML from the user in all cases. Working with some of the better tools I see that I am authoring and editing tons of XML without even knowing it.
  5. I don't think XML is going to die very soon ..
  6. ant bsh configuration[ Go to top ]

    Maybe you can jam out a script that will uppercase the first letter of your sentences as well as proper names. If you really get crazy you can get the script to put 2 spaces after each period.
  7. Maybe you can jam out a script that will uppercase the first letter of your sentences as well as proper names. If you really get crazy you can get the script to put 2 spaces after each period.
    The lack of uppercasing is unforgivable, but we must give up these antiquated notions of typography. Two spaces after the period is no longer needed. It dates back to the monospace fonts of the typewriters of long ago. Modern font designers design their fonts for a single space.

    So, his Groovy script should REMOVE that extra space, not ensure it exists!

    The link below is a video explanation by Bill Hill, a leading typography expert (working for Microsoft, interestingly).

    http://channel9.msdn.com/ShowPost.aspx?PostID=112
  8. As long as XML dies...[ Go to top ]

    As long as something kills XML as the configuration language, I don't care what it is. Enough of this insanity already.
  9. As long as XML dies...[ Go to top ]

    Wow, you make a very convincing argument. Do you care to share with us what's wrong with XML as configuration language. We feel it is a nice way to configure stuff and the tool support is great all around.
  10. As long as XML dies...[ Go to top ]

    Not sure how well this go down, but XML is good for defining and storing data. You can create reuseable targets such as "compile" "jar" which perform one fine-grained task. Your script could then init the build and check the result of each target, depending on the result of the target, the script can control the flow of the build.

    Now you won't have configuration data (such as hard-coded directory locations) in your scripts, they use logic to control the flow only, and you have very reuseable build.xml files. When you move to a different project you only need to code new logic, or perhaps pass in new parameters to fine-grained, generic targets.

    Seeing as Spring doesn't use logic in its config files (from any examples I have seen), why would it be better to hard-code mutable values in a script?
  11. As long as XML dies...[ Go to top ]

    I disagree that developers spend too much time parsing XML.

    For configuration:
    If you use spring you do not need to write on line of parsing code.
    There are other nice tools out there as well. Jakarta digester!

    For B2B communication it will be the standard for a long time to come:)
  12. Groovy and BSH to kill XML :)[ Go to top ]

    Interesting issue. There's a lot of interest among Spring developers in providing additional configuration options. (We'll always keep our XML, and it will always be backward compatible.) Note that Spring's architecture is not tied to XML definition files. Configuration parsing is already completely separated from the actual IoC container. Multiple configuration sources can even work on the same container.

    I also must say that personally I expect I would continue to use XML Spring configuration with Eclipse and XML Buddy, or the Spring Eclipse plugin. With context prompting and a decent DTD, I never type XML tags. Normally I'm not a fan of relying on tool support, but Java and XML are both fundamental things, which need to be done and need to be made easier. Even if a typical J2EE developer who used Spring were to shift to some other configuration means for Spring, they would still need an XML editor for other stuff. A good XML editor is as important as a good Java IDE that supports refactoring IMO.

    However, in general I don't believe in imposing my own views (or those of the dev team) on Spring users. If Spring users want other configuration formats, they will get them, and it won't complicate the implementation of the IoC container proper.

    As it happened, I spoke to James about potentially looking at Spring/Groovy synergies together this morning...

    Regards,
    Rod
  13. http://wiki.apache.org/jakarta-hivemind/NotXMLProposal
  14. Groovy and BSH to kill XML :)[ Go to top ]

    Looks similar to what I've done in a past life (96) on Windoze applications with their excellent activescript engine. Script snippets to config things or respond to events. I don't know if it will replace something like XML though, the example in the blog isn't that convincing and if you look at how tooling can generate that type of thing, I still think XML is easier to generate rather than a 'program' to do the same thing, chances are the XML would be easier to read and modify for most people than the script.

    Billy
  15. Why Not Java?[ Go to top ]

    I agree that XML has to die as a configuration language. Until I can get Eclipse to understand and work with Groovy or Jython just as well as it does Java, why not just write configurations in Java? With an IDE I can get warnings, completion, integrated refactoring (what happens when I configure a class name in groovy, but then refactor that class name w/ the IDE? I have to then do a search and replace). Our IDEs these days are so nice, by moving to a language that isn't supported, I might as well be in XML.

    Granted, I like Jython, but I want it as supported in my IDE as Java. Until then, I'll stick with Java. Quicker and easier, thanks to the IDE.
  16. Why Not Java?[ Go to top ]

    Finally ! I so agree.

    As soon as you get into that grey zone that divides "configuration" from "wiring", you might as well do it in Java. That's why I'm terribly split about spring's context xml. As long as I'm configuring username, password, db url, driver name, ... it's serious overkill. But in a second, we're looking at stuff like this:

    <bean id="myProductDao" class="org.springframework.aop.framework.ProxyFactoryBean">
    <property name="proxyInterfaces">
    <value>product.ProductDao</value>
    </property>
    <property name="interceptorNames">
    <list>
    <value>myHibernateInterceptor</value>
    <value>myProductDaoTarget</value>
    </list>
    </property>
    </bean>

    Is that configuration ? No. Who's supposed to edit this ? Someone who's well able to handle a compiler.

    Actually, I'm pretty confident that a well-designed API (call chaining, no ugly "get" "set" prefixes, ...) could make a Java-BuildFile more readable and tool supported than an ant xml. For an example of a well readable, terse and still extensible API look at JMock:

    mock.expects(once()).method("perform").will(returnValue(OK));

    Would be even nicer in Smalltalk ... Imagine that bean-style or in XML ...
  17. Why not Java? Really, why not?

    The advantage of XML configuration used to be "configure without programming". Sometimes it get skewed to "configure as much as you can via XML, even if you end up with a programming language". Sure, you can define a programming language with XML but what for? What are the chances your language will stay stable to give the people the time to learn it? Documentation, debugging, backward compatibility, evangelism -- you sure need to take care of all that?

    In other words, let's better make sure the stuff is well-designed and modular so that the application designer can easily (re)wire components in application-specific Java file(s) and keep these separate from the framework. It is their job as an application designer anyway, so let them use the tools they know best. I'd say the ability to wire in Java *without* the use of the configuration files should be mandatory feature for frameworks.

    Configuration files are for things that *really* need to be configured, like trace levels, database connections, directory locations, ports etc.. Files are small, they can be XML, .properties or whatever works best.

    One area where XML works really well for me is in configuration maintaned by the program itself -- reasonably easy to program but still readable when you need to debug it.
  18. Full circle[ Go to top ]

    I may be showing my age here but it looks like we have come full circle. When I started my career, I was a C/UNIX guy. Back then we did builds using shell scripts where we had complete control of the build process. Finally we moved to Makefiles. Some of the control was turned over to the underlying make subsystem. In return for this, the Makefiles were (supposed to be) simpler than just plain old scripts. Jump forward to Java, Makefiles proved to be inefficient for Java so we moved to Ant. The build.xml file for Ant, is essentially an XML version of the old Makefile (conceptually identical - targets, tasks etc.). Due to it's declarative nature a small number of projects may require greater control in the build process. And so the pendulum swings back to using scripts for the build process.
  19. Humans and XML[ Go to top ]

    As has been said, it's all about the visual tools abstracting the XML. Tools work better with XML rather than with properties files, etc...humans don't. We're not supposed to be editing that nasty XML by hand.
  20. Kill, kill and kill, ...[ Go to top ]

    I don't really understand this, but I see that TSS has already 2 topics of "something tries to kill something", just in one page! -> IBM tries to kill Microsoft, Groovy tries to kill XML... what next? ;-)

    IMO this is not a good way because at the moment we still don't have a peace on earth, right?

    Anyway, I really don't believe that Groovy can take over the function of Ant ;-) (just like others who think that Maven can replace Ant ;-)). Instead of doing something like this it would be much more cooler to build an Eclipse plugins for Ant task. So, the work to make/extend Ant task will be a lot more easier. So if you need more than what Ant offers you, you can write your own Ant taks with Java easily...

    Thanks!
    Lofi.
  21. I like Groovy, yet another 80% finished gadget from James who seems to just ooze code everywhere he goes. I've a great fan of Jelly too, sort of the same thing but more XML oriented.

    While I'd love to see another nail in the coffin of XML I don't think this is it. It will definately have its place and a good one at that but one of the "nice" features of XML, if you can call it "nice" is that when you use it for scripting, a la ANT or Spring it can also be easily reverse engineered, i.e. you can got from program to XML and from XML back to program, I don;t need a language parser to display the functionality of an ANT script on a GUI. Chuck it in a DOM or something more sophisticated like a Java model and you have read/write access to your model and rules.

    As I'm sure most of you know, we (C24) generate code, with the code we generate a customised ANT script to compile/JavaDoc and run the generated code, we do the same for Maven and it's quite frankly very easy to do with XML even if the user supplies his/her own ANT script since we can read it in, understand the XML, modify it and then write it back. I've used Groovy for builds and it's pretty damn cool but I wouldn't want to have to do said task with Groovy.

    So, kill XML, no, compliment it and provide yet more integration between Java and XML yes.

    Great tool James, keep up the ideas and coding, may be you'll get a regular job one day. :-)

    -John-
    CTO, C24
    London, UK
  22. Check NanoContainer![ Go to top ]

    NanoContainer is basically a collection of scriptable front ends for PicoContainer, including support for Groovy. NanoContainer provides the following script flavours for PicoContainer

    o Groovy
    o Beanshell
    o Jython
    o Javascrip (Rhino)
    o XML (to die soon? keep dreaming!)

    You can easily roll your own in COBOL...

    http://docs.codehaus.org/display/NANO/NanoContainer

    Aslak
  23. Doesn't Look better to me[ Go to top ]

    Just read the article. Well, having played around a little with Spring, the groovy example configuration seems worse to me. The XML was easier to follow. Maybe I just don't get it. Could be. But, maybe I do.

    The Groovy example smells of programming relationships instead of defining relationships as data. In this case, persisted as XML.

    Seems like folks are soooo onto the latest techno craze. <STRONG>Smells of technology looking for a problem to solve.</STRONG> Give it 6 months, something else will grab their attention.
  24. Agreed.[ Go to top ]

    I think you hit the nail on the head.

    I think we are crossing a boundary when we need a scripting language to configure our application. There needs to exist a clear boundary between our application code and the meta / configuration data associated with it.

    XML is declarative in nature and has well defined semantics through a schema or DTD - which seems to me to be more appropriate for application configuration.
  25. Is it better?[ Go to top ]

    XML is a standard, we need to parse it, maybe it need code writing.But it' s convenient,it's mostly wide used for many systems. Script language maybe easy than xml file, but is it mostly wide used than xml? Can it become a file format? If many systems use differenct script language to config their system, how about the learning curve? Futher more the config file should be text based and not be scripted based, those will not be more clearly and readably.
  26. Groovy and BSH to kill XML :)[ Go to top ]

    I agree that XML is too bloated for the amount of information they hold.
    But XML has the advantage that you can change it with the DOM API, and this in fairly all languages, not just java.
    Changing a file that contains groovy code would be a hard job.
  27. I think the question is not so much about the use of XML in configuration but rather its abuse. Lot of people have already said this: XML is pretty good at representing hierarchical data but when we start providing instructions in XML that's when we are crossing the line.

    I think configuration is a sweet spot for scripting languages. Its no rocket-science to write/understand and there are no parsing hasles. I just haven't seen a single convincing argument to not use scripting languages for configuration yet.
  28. Go on Sing it...[ Go to top ]

    Well, I start a blog and I get quoted on the serverside immediately. That's life on Internet time I guess.

    First, no disrespect is intended to the architects of any projects that utilize XML files. However it's plain that a considerable amount of effort has been expended and will continue to be expended on writing code to parse configuration XML files. I had intended on using a Groovy script to generate a Hibernate mapping but cut off the effort after deciding it would take too much time to trace through the XML parsing code to determine which objects are created.

    As previously mentioned in this thread XML does have advantages as a representation that can be more easily transformed into another form such as documentation (Although a Velocity template acting upon
    the beans configured by a Groovy script would work as well, but code dependencies would have to be satisfied).

    I did question the need even for Groovy to be used as the scripting language, Why not just drop down to Java? I'm sure that I could play enough tricks with my class loader to reload a class with an updated configuration encoded in it, but I wanted to try out something with Groovy.

    As to legibility of the example vs XML. I think it's as least as easy to comprehend the examples in Groovy vs XML. The real stumbling block might be that certain classes, like RuntimeBeanReference, RootBeanDefinition and ChildBeanDefinition have up to now been masked by the XML configuration files. Perhaps the answer lies in documenting the JavaBeans style of configuration (I would be willing to help) so that alternative configuration mechanisms could be developed.

    Finally, the title of my posting "Groovy killed the XML file" was absolutely tongue-in-cheek. It should be sung to the tune of "Video killed the Radio Star" by the Buggles. See this version if you're too young to remember the original.