Recently I was having some issues with the Ant files for a software project I was working on. I was editing one of them in XMLSpy but wasn’t getting entry help or code completion because I didn’t have a schema assigned to my script.
That seemed like a simple problem, so off I went looking for the schema.
I quickly found a Stack Overflow question looking for the same thing. The answer turns out to be, there is no Ant schema or DTD. The reasoning is straightforward. Above the challenge of making a flexible and comprehensive model of the Ant core, it would be able to include all the external tasks.
I immediately remembered that I’d been here before a couple years back, but this time I figured I’d use XMLSpy’s schema generation feature to try to do something about it…
If an official schema isn’t going to happen, you can use XMLSpy to quickly create one that covers the specific tasks and features you use. As you use more features, adding to your XSD is a very minor effort in return for getting great editing support and validation help.
XMLSpy can generate schemas from a set of XML files. The way this works is that you create a project by selecting New Project on the Project menu. Make sure the Project window is open, if not use the Window menu to open it. Then add your Ant files to a folder in it by right-clicking the folder and selecting Add Files.
After adding the files, right click on the folder again and select Generate DTD/Schema.
My project has dozens of Ant scripts, so we have a pretty representative scope of Ant usage for the development we are doing. That means that XMLSpy will see all the different ways we use Ant and will generate a schema that covers everything we have done with Ant so far.
Generating the schema was a snap. That said, as good as XMLSpy is at generating models, when you feed it 60 Ant files you are bound to get a sprawling schema. You can see my selections in the Generate schema dialog in this screenshot. The most important options for me were to get global types and few enumerations to simplify extending the schema.
Before prettying up the new XSD I had to decide what I wanted out this effort.
Ant is hugely flexible and allows for all kinds of values in attributes, and many external tasks are not namespaced. I didn’t want a perfect schema, just one that would be helpful for this project. My goal was to have a very flexible schema that allows XMLSpy to offer entry helper support when I am editing Ant files to speed things up.
Longer term maybe we will want to tighten it up a bit to help us write consistent and correct Ant files, but that is in the future. But first I just wanted a super simple proof of concept.
With this in mind, I started trimming down the generated schema. XMLSpy generates XSDs that cover every case exhaustively. It gave me a technically correct schema, but one that had a bit more specificity then I wanted or needed. But in the XSD view all it took was a few minutes of dragging elements around and consolidating unnecessary branches to get to a very straightforward model.
The first proof-point was in when I could validate all ~60 Ant files against my simplified XSD. After adding back a few elements that I’d unintentional lost during my clean-up I was in business. I right-clicked on my project folder and selected validate all. Everything validated in a quick 5 second batch.
The second proof point was getting the context-sensitive help from XMLSpy as I created a new Ant file. Very quickly I realized there were going to be lots of new elements to add over time as we used new tasks and features. For example I found I needed to add the <sysproperty> element to <junit> because we hadn’t used it before.
But adding an element or attribute here or there is simple in Schema View, and over time we will need to do it less and less.
Overall, for my simple purposes, creating an Ant schema turned out to be a nice little victory.
If you would like to use my very basic schema as a starting point for creating your own, go ahead and download it here. And let me know how it works for you.