After watching John Paul Ashenfelter's Pragmatic ColdFusion: Build, Test, Deploy preso I decided to try hacking up one of my Ant build scripts to use an external property file. It seemed like this would be a bit more flexible.
I initially just copied all my property statements from my build.xml's "init" target to my external property file. And things ran up to a point and then I ran into
In my build.xml
-
<property name="project.build.src" value="D:\build\${project.name}"/>
In my common.properties file (note double slashes)
-
project.build.src = D:\\build\\${project.name}
Or you could do (note forward slashs)
-
project.build.src = D:/build/${project.name}
Also references to UNC paths changed:
In build.xml
-
<property name="project.build.dev"2 value="\\myserver\${project.name}$" />
In common.properties (note forward slashs)
-
project.build.dev = //myserver/${project.name}$
I've got a few properties still buried in my script that are dependent on certain targets but I think with a bit of tweaking I can reference those externally as well. Then ideally any developer on our team can simply tweak the external file without messing with the more complicated build.xml.
This article contains a few more good tips: Flexible User and Environment Ant Configuration which I'm going to implement as well.
You May Also Enjoy Reading:
One Comment
MUCH more flexible, IMO. Having used properties files for a year or so, I’ve refined them to such a degree that I have “base” properties and build files which can be refined on a project-by-project basis. Once the project build file is complete, only the properties file needs to be modified in order to build/deploy that project to multiple servers (dev, staging, prod, etc.). Works beautifully.
Properties files are easy to modify, script files…less so, I think.