Monday, September 23, 2002

Not an Optional Extra Not an Optional Extra. Too much of the marketing of development environments seems to ignore the fact that the thing coders spend the majority of their time doing is either writing code, or thinking about writing code. ìJust fill in this wizard, and you've deployed your very own web serviceî does not impress me much when all the service does is say ìHello Worldî So long as you follow the advice of the Pragmatic Programmers and automate everything you're likely to do more than once, it's pretty easy to get around the absence of specialised tools for things like EJB development, application deployment and so on. All the development environment needs to do in that situation is stay out of the way (which some do better than others). On the other hand, you're unlikely to want (or have time) to write a fully-featured editor or code-navigation tools, and these are the two things that help you write code, and think about writing code. The reason Intellij IDEA is so cool is that they started with the plan ìlet's write an environment for writing code, and thinking about writing codeî. With that and the hooks to Ant, JUnit and CVS, there really wasn't much you couldn't make it do. A guy from Sun was giving us a sales demo for SunONE Studio on Friday, and all the questions that sprung to mind about it were a checklist of IDEA editor features. Does it have smart templates? Refactoring support? Java context-aware searches? Amongst all the things SunONE Studio could do with EJBs, web services, web applications and so on, refactoring turned out to be a third-party plugin. To me, this is like shipping a car with air-conditioning, mag wheels and a turbocharger, but it's stuck permanently in first gear until you buy Rational Gearboxô [The Desktop Fishbowl] Totally agree. IMHO putting all these bells and whistles for EJB, Web Services etc into an IDE is a bad thing. IDEs are very personal, subjective  things. There are quite a few to choose from as well, eclipse, netbeans, IDEA, jbuilder plus good old emacs too. Its far better to have these things part of your build process (via Maven or Ant), then anyone can use your code from any IDE rather than expecting your whole development team to standardize on a single IDE just so they get some nice wizards to create or deploy EJBs or Web Services. 12:33:30 PM    comment []

XML Scripting XML scripting. Here's a nifty XML scripting idea, by way of Collaxa's Blog (thanks, Edwin): ... [Jon's Radio] Interesting. Though I'm not yet convinced that we need yet another scripting language just to be able to script XML. Unsuprisingly enough, I prefer the Jelly approach. Use XML to define scripts then embed off the shelf scripting languages (such as beanshell, Jython, Jacl, JavaScript, pnuts) inside the XML where/when scripting is required. Or plug in native support for Velocity and JSP style expression language, Jexl, as well as native XPath support, SQL support. IMHO, benefits of the Jelly approach are Scripts remain XML. So any XML tool can be used to analyse, process, filter, transform the scripts. No need to invent Yet Another Scripting Language with clumsy XML infoset + scripting language syntax. Just use XML with any off the shelf parser then embed your scripting language of choice Jelly is totally extensible using XML namespaces to provide all kinds of functionality instead of just 'XML scripting' such as invoking SOAP services, working with beans, SQL, XSLT as well as having support for Ant tasks and JSTL. Jelly can work in a SAX based XML pipeline mode (like Cocoon), or can work with DOM tree fragments, can work with XPath, can invoke XSLT or can work with arbitrary Java objects. Plus its easy to use declarative rule based matching (like XSLT), or procedural iteration over XML via XPath. The XML Scripting language shown in this story only seems to work on DOM fragments using XPath. There are many different ways to script XML, Jelly supports them all. Jelly is open source under the Apache licence.  Will BEA be open sourcing their scripting engine? 12:28:14 PM    comment []

JMX and Messaging links While doing some random googling today via the 'google it' buttons, I stumbled across some handy looking JMX links which include various interesting looking open source projects such as WebJMX and JMX4ODP. Also there's this links page at xmlblaster. (I've already mailed Marcel to submit several more projects I'm aware of). 10:49:57 AM    comment []

MC4J and MX4J JMX Implementations. MC4J is released as open source. For those using JMX it looks like there's a new Swing based management console thats open sourced called MC4J. Might be worth a look; the screen shots look pretty good. [James Strachan's Radio Weblog] Looks cool. That combined with MX4J seems to offer (from reading the webpages) a fairly comprehensive open source generic JMX solution. [transMorphic] I have to ask the stupid question, is sun going to allow these guys access to the Technology Compatibility Kit. [Brett Morgan's Insanity Weblog Zilla] Dunno. Its not really an issue for MC4J which is a Swing UI tool for viewing/editing any JMX configuration.  Though it is an issue for MX4J however already MX4J is a standard part of Tomcat's distribution and I think its also included in JWSDP which Sun distributes. Basically noone should use the JMX reference implementation - it has many problems, use MX4J instead. At JavaOne last year Sun did commit to making all the TCK's available to open source projects. Dunno if they've gotten around to sorting out the JMX TCK yet though... 8:36:57 AM    comment []