Hmmmm

Image by law_keven via Flickr

http://news.bbc.co.uk/2/hi/uk_news/8056284.stm

"For decades, hundreds of people worldwide have been plagued by an elusive buzzing noise known as "the Hum". Some have blamed gas pipes or power lines, others think their ears are faulty. A few even think sinister forces could be at work.

...

"The internet is abuzz with rumour and speculation. There are dark mutterings about secret military activity, alien contact and government cover-ups. The hum even featured in an episode of the sci-fi drama "The X-Files"."

Blogger and Escaping HTML

Image by grebo guru via Flickr

While attempting to create a blog post containing a couple of XML fragments, I ran into a surprising problem with Goggle's Blogger editor. It is staggeringly difficult to get greater-then and less-then signs into you text!

I Goggled up this other blog post that sums up the problem nicely:
http://justfreakingwork.blogspot.com/2007/06/why-cant-blogger-escape-special.html

It's a little hard to believe in this day and age that Google has made such a mess of this.

Headless Build Automation for Netbeans BPEL Projects

There is a great deal of mystery surrounding the Netbeans/Glassfish/OpenESB build process. I'll include here a few details for others that may be interested, but it appears that a headless build is not possible or practical at this time. If you're looking for a solution, you won't find it here.

When I first started using Netbeans I was encouraged that it used ant for its builds rather than some process implemented as part of the IDE. However, in practice, doing a build outside the IDE turns out to be not only non-trivial but extremely complex, and may be impossible in some cases. For example, in the case of a BPEL project that includes a WSDL dragged into the BPEL editor from another project...

When a WSDL from a separate project is included in a BPEL, the tag's location cause looks like this:

<import namespace="http://myns" location="otherProject/my.wsdl" importType="http://schemas.xmlsoap.org/wsdl/"/>

where "otherProject" is the project containing the web service being used. WSDLs from the local BPEL project look like this:

<import namespace="http://myns" location="my.wsdl" importType="http://schemas.xmlsoap.org/wsdl/"/>

This location tag is not an operating system file path. "otherProject/" in the above example can be anyplace on the system relative to the project being built and the the IDE somehow finds it. Using "file://something" in the location tag is apparently a syntax error. It's hard to say what this location tag actually is. At the moment, I don't know.

Outside of the IDE, a location tag such as the above fails to find the WSDL file during the build. The failure occurs in at least two java classes that the build script invokes.

org.netbeans.modules.bpel.project.anttasks.cli.CliValidateBpelProjectTask
org.netbeans.modules.bpel.project.anttasks.cli.CliGenerateCatalogTask

Somehow these classes are able, in the IDE, to map the location tag to a physical WSDL file. The only reference I could find to these location strings is in the catalog.xml file in the project's base directory. But removing these does not create a build error in the IDE, so that can't be how it knows. Is there some internal database in Netbeans tracking these references? Hard to say.

A good deal of essential information on building Netbeans projects outside of the IDE can be found here:

http://blogs.sun.com/tronds/entry/creating_a_simple_headless_build

This information is vital to getting started with the build environment, outside the IDE. That setup may be enough for most projects, or at least projects other than BPEL projects that refer to WSDLs in other projects.

GUI-only builds is a very surprising limitation, but there it is. It seems we will have to replace the build scripts for our projects. It would have been better to know about this a long time ago, before beginning projects using this otherwise really quite nice technology.