Three assumptions in this process are:
For my TypewriterFX application (which plays Mac OS X typewriter sound effects), I wanted/needed to control the JVM that was used to run the application. The way it works, TypewriterFX plays sounds as fast as it can -- as fast as you type -- so I needed the JVM to be more like the old client JVM than a typical server JVM.
Summary: An Ant date and timestamp (tstamp) task example.
I was just digging through some Ant build scripts I've created, and I noticed a segment of a build script that first creates a timestamp, and then uses that timestamp in the process of creating a manifest file. (This build script is used for building a Java Swing application.)
Here's the code from my Ant script that does this timestamp magic:
A lot of times when you're working on a Java web application you only need to deploy your JSP files. This happens, for instance, when you're just editing the JSP files to modify the look and feel of your web application. In cases like this there's no need to rebuild your entire application, deploy it, then restart your application server (Tomcat, Glassfish, JBoss, whatever).
Ant war task example: Here's another snippet of code from my most recent Ant build scripts. This example code shows how I use the Ant war task to create my war file:
Ant replace FAQ: Can you share some examples of the Ant replace task?
I've been sharing a lot of Ant tasks lately, and here's another example, this time some Ant replace task examples.
Ant replace task examples
The Ant build script lines shown below demonstrate how to issue a series of Ant replace commands to replace a token in the file with a variable you want to substitute for that token:
Summary: An Ant classpath example.
Here's a quick example showing how I typically build a variable to represent my classpath in an Ant build script.
Our Ant classpath example
This snippet of code below shows how I use the Ant fileset task to create a variable named
class.path by including all jar files from my lib directory using the pattern
**/*.jar. This syntax can be read as "Include all files named *.jar in the lib directory and all of its sub-directories".
In the category of best practices I have to include my thoughts today on unit tests as a form of "comments/documentation you can compile". Let me explain:
I recently had the experience of (a) working on a small but complicated software development project, (b) leaving that project for six months, and then (c) being asked to work on it again. All I can say it wow -- what a great experience it was to come back to a project that was loaded with unit and code coverage tests.