One of the things I like about NetBeans is that things ‘just work’ out of the box. The XML editor is one of those things that generally works very well. One place where this doesn’t seem to apply is when you’d like NetBeans to validate an XML schema file. I was working on a JAXB document and ran into this problem again. When you right-click and choose Validate XML, NetBeans complains that it can’t find the definition for xs:schema. I think the problem is that the schema URL for XML Schema doesn’t actually return an xsd file. Apparently NetBeans doesn’t have a built-in rule to resolve this schema.
Fixing the problem isn’t too hard, but I don’t know if it’s documented anywhere. First, create an XML catalog that resolves the schema URL to the XSD file:
<?xml version=”1.0”?>
<!DOCTYPE catalog
PUBLIC “-//OASIS/DTD Entity Resolution XML Catalog V1.0//EN”
“http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd”>
<catalog xmlns=”urn:oasis:names:tc:entity:xmlns:xml:catalog”>
<uri
name=”http://www.w3.org/2001/XMLSchema”
uri=”http://www.w3.org/2001/XMLSchema.xsd”/>
</catalog>
Now go to Tools/DTDs and XML Schemas. click on Add Catalog, click on Browse, and then choose the file created above. This is an OASIS type catalog.
Now NetBeans will be able to resolve the schema definition and happily validate XML Schema files.
Up until yesterday I was successfully running Digi’s X-CTU application (which is a Windows app) using Wine on an Ubuntu VM. This is not a very nice app, but it is the only official way to update firmware on XBee modules. In fact, it’s the only way I know of to update the firmware on an XBee. Although I have a Windows VM that I can boot up, it always seems like a big hassle when I just want to reconfigure an XBee module. Had I realized what a hassle this was going to be I might not have chosen XBee modules.
So yesterday I had two new XBee modules that I wanted to configure. These new modules had a newer version 10E6 of the firmware on them from the factory. X-CTU recognized the modules were connected but complained when it could not find a configuration file for that firmware version. I let it try to update from the Digi site, but it returned an error saying that the server was busy. That was odd. I downloaded the 10E6 firmware zip from the update site (working fine for me!) and told X-CTU to update from the file, which it was happy to do. But it still complained that it did not have the 10E6 files. I booted up the Windows VM and everything went swimmingly. The software was able to download updates from the Digi site and it had no problems with the 10E6 firmware.
I think the problem is that the firmware files say that the firmware version is 10e6 rather than 10E6. On Windows, this is not a problem, but on Linux the file system does not like this difference. Of course, the software is not meant to run on Linux and Digi emphatically states that they don’t support the software on anything other than Windows.
Now I’d like to see if running on a case-insensitive file system would fix the Wine problem.
I’ll be presenting a talk at the Open Source Bridge conference in Portland sometime between June 1st and 4th. My talk will be about a wireless temperature sensor and control system that I built using some dusty electronics knowledge and a truckload of open source (mostly Apache stuff) Java software. The wireless aspect of the hardware is provided by XBee modules. The main things that I will be talking about on the software side are Apache Mina and Apache Felix. Mina provides a nice library for handling custom protocol that XBee modules communicate with while Felix provides a nice base platform for the application to run on.
Installing Wine using MacPorts wasn’t working out very well for me. I think the main problem was that I had built most of my ports under 10.5 and then upgraded to 10.6. Having a fresh need to run Wine, I decided to start over from scratch with MacPorts. I blew away my existing installation and re-installed the latest binary.
On 10.6, you have to use wine-devel. So I did that. Things seemed to be going well until all the dependencies were built and wine-devel was configuring. It then announced that it couldn’t use the installed dependencies because they were built only for x86_64 and it needed them for i386. So, I had to go back and build each of the dependencies with the universal variant so that both i386 and x86_64 variants would be built.
Now it works, although the experience is not as nice as on Ubuntu. That’s mainly because I can’t double-click a shortcut to start an application.