I have been using Ant, in some form or another, for project deployment for quite sometime. Recently, we released Ant4CF, which I love using, as it makse the process of updating your deployment scripts much easier than the process I was following. However, there were a few unexpected behaviors I ran into when setting up Ant4CF the first time.
First, I used to run all my Ant tasks from inside of Eclipse. Simply right-click, then choose ‘Run as…’ –> ‘Ant Build’ and Ant would take care of what needed to be done. When I started using Ant4CF, I would get an error when running the Ant task:
/Users/blah/Sites/usdaa/wwwapp/Deployment/DevBuild.xml:5: java.lang.UnsatisfiedLinkError: Cannot load 32-bit SWT libraries on 64-bit JVM
After chatting with Doug Hughes about this, we determined the issue stemmed from the fact that I was using an older version of Eclipse that did not allow me to run the tasks from Eclipse. After chatting with Chris Peterson, another Alagadian, he informed me that he is running the 64-bit version of Eclipse 3.5 (Galileo) and that he could run Ant4CF tasks without issue. I went and downloaded Galileo and my Ant4CF tasks run withoiut issue. If you are using Ant4CF and run into a similar error as above, try updating your Eclipse to a newer version, or even a 64-bit version and you should be good.
Next, when creating my deployment scripts, I used the XML tasks that are used in some of the samples in the Ant4CF documentation. These work great for being able to find specific values or nodes and modify them. This is often necessary to set configuration settings based on the environment (staging vs. production, for example). When I ran these scripts, they worked without issue, but when I checked the web application I was getting a lot of weird errors with ColdSpring, such as incorrect values being passed, or values of the incorrect type being passed.
This took some serious investigation. I was looking at my ColdSpring.xml files on my local machine and the XML attributes that were reported as causing the issue were not there. Not that they were set differently, they were not set at all. I looked at the ColdSpring.xml file on the server and the first thing I noticed was that the documents formatting, in terms of spacing and line breaks, was different than my local file. It also had a lot of attributes set that are not specified in my local copy. After a lot of trial and error, I determined that the issue stemmed from my document declaration in the XML file and specifically the DTD that was specified. It appears that the XML task actually rewrites the entire document based on the DTD, and in my case caused a lot of issues. The simple solution was to remove the reference to the DTD from my local copy of the file and re-deploy. This time everything worked as expected.
Finally, after I was able to get all my tasks running, and files updated as needed, I had to add a CF Admin specific task to clear the trusted cache. Before I go any further, let me explain the process I follow to do deployments. I typically set up a ‘web site’ on the server named something like ‘deployment.clientName.com’. I then drop all the Ant4CF files into the root of this site and add HOSTS file entries pointing URL to the server’s IP address.
When I added the task to clear the trusted cache, it would fail at this step. After doing some poking and prodding in the Ant4CF code, I discovered that Ant4CF actually makes an HTTP request to the proxy file sused to handle the CF Admin API functionality. This is actually run in the server, not on my local machine. Can you see the problem? The task would fail because the server couldnot resolve the domain name ‘deployment.clientname.com’. I added a HOSTS file entry to the server for ‘deployment.clientName.com’ and everything worked as expected.
DougHughes.net 