Ant Build Templates: Prelude

Posted on Tuesday, September 9th, 2008 at 8:41am by Rob Wilkerson

I’ve long been an Ant enthusiast and advocate for its use beyond simple Java compilation tasks. A while back, I wrote a post, available in my InstantSpot archive, describing how I employ Ant to build and deploy web applications. It was intended to be the first in a series, but additional posts just never materialized for a number of reasons. Abort.

In that post, I somewhat casually mentioned that I had created a build template that meets my needs for most projects. More people that I expected caught that casual mention and have asked me to post those templates. I’ve procrastinated in doing so, at least in part, because I didn’t feel like these scripts were ready for public consumption. They were built by me, for me and specifically to meet my needs. Not exactly stellar code, but code that functioned the way I needed it to function.

One of the things I’ve been doing over those past few months of procrastination is editing the script templates that I use. In little snippets of time between then and now, I’ve finally managed to make and test those changes. Not only have I added comments and generally gotten the code to a point where I wouldn’t be mortified to have it go public, but I’ve also tried to make the script a little more robust than the original version(s). I’ve:

1. Added sanity checks that provide an opportunity to cancel the build before any significant damage gets done.
2. Added a more robust backup of any existing version that already exists in the deployment environment.
3. Included a modicum of intelligence so that the script detects its deployment environment and does the right thing based on that environment.
4. Included a secondary path to handle upgrades in addition to new installs.

All of that said, these are not generic scripts that can be dropped in anywhere. They make a lot of assumptions that may be specific to my environment. The scripts should be (relatively) easily tailored to other environments, but should not be expected to run without modifications. To that end, I’ll build up to revealing the scripts by providing the background information that I think is necessary, important, appropriate or just plain prudent. Some of this has been covered in other posts in the archive, either here on robwilkerson.org or on InstantSpot, but bear with me. I think it’ll be helpful to have it all in one place and focused.

My goal is to write a post each day on the following topics:

1. My Environment
2. My Process
3. Two Files or One
4. External Tasks

Once I’ve provided that background, I’ll link the scripts under an MIT license. At any step along the way, I’d certainly appreciate any (constructive) input. I’d like to think that I’ve thought of everything, but I’m old enough to know better.

ant, build 3 Comments

Remove Console Output Limits in Eclipse

Posted on Friday, September 5th, 2008 at 8:00am by Rob Wilkerson

I run a lot of builds. I run the vast majority of those builds directly within Eclipse taking advantage of its integration with Ant and some of those builds are large. More accurately, some of those builds are verbose, whether it’s because I’m explicitly documenting what’s happening for later debugging or whether there’s a lot of output from a given task (svn export is a perfect example) that’s being displayed. Sometimes there’s so much output that the console’s buffer discards a portion of that output and prevents me from debugging effectively if a problem arises.

By default, Eclipse limits the console output buffer to 80,000 characters, but this can be changed easily enough. In my case, I like to remove the limit all together:

1. From the menu bar, go to Window > Preferences > Run/Debug > Console.
2. Uncheck the box labeled Limit console output.

With that limitation removed, I can access the unabridged version of my build output. This setting is not specific to Ant, of course. It will remove the buffer size limit for any action that directs output to the console.

ant, eclipse, configuration 2 Comments

Run Eclipse-Installed Ant from the Command Line

Posted on Thursday, August 21st, 2008 at 7:04am by Rob Wilkerson

In the midst of my transition to Linux at work, I’m also working on updating the Ant build script templates that I’ve used for years to deploy every project I/we develop. When I built my Linux box, I installed Eclipse using Pulse. More often than not, I run my Ant scripts from within Eclipse (I love that integration), but from time to time it’s expedient, for one reason or another, to execute a build from the command line.

In previous lives, I’ve installed a standalone copy of Ant and used that for command line execution, but this time I was feeling thrifty. Clearly there’s an Ant executable baked right into Eclipse, which I already have installed, so why can’t I just use that one? Well, no reason, except that I didn’t know the path to said executable. So I dug around.

As you might expect, this is not a difficult problem to solve. I found my Ant root directory by looking in Eclipse under Window > Preferences > Ant > Runtime. On the Classpath tab, the first expandable group is named Ant Home Entries. Expand that to see all of the libraries that exist in the native classpath or, more importantly for this purpose, to see where the Ant home directly exists. To find the Ant home directory from these library paths just drop the /lib/[…].jar part of the library path. On my Pulse-installed instance, doing that leaves me an Ant home directory of /home/[user]/Applications/Pulse/Common/plugins/org.apache.ant_1.7.0.v200706080842.

Once you know the home directory, all that’s needed is to set a couple of environment variables and you’ll be able to run the Eclipse-installed instance of Ant from the command line or Eclipse.

For Linux and Mac users, edit your shell’s login script. In my .bash_profile, I added the following lines (syntax will vary for other shells):

export ANT_HOME=/home/[user]/Applications/Pulse/Common/plugins/org.apache.ant_1.7.0.v200706080842 export PATH=$PATH:$ANT_HOME/bin

Once you’ve saved and quit the editor, ensure that you “source” your modified script (or exit the terminal and return or even just open a new tab) to activate your changes for the current session:

$ source ~/.bash_profile

That’s it. To test, just type “ant” at your shell prompt. Ironically, Ant is alive and well if you get a failure message:

$ ant Buildfile: build.xml does not exist! Build failed

That’s it. Linux and Mac users can go on about their day.

Windows users will have to set/update the ANT_HOME and PATH environment variables in Control Panel > System > Advanced > Environment Variables. Windows users may also have to restart in order for their changes to stick unless they also set those values at their own command prompt for use during the current session. For the values to persist beyond the next reboot, though, the first method is required.

ant, eclipse, linux, windows, mac 0 Comments