牛仔褲的夏天

Just kidding! ANT is a Java based building tool, which is similar to make, and so much better than make.

ANT, what a smart name for a building tool, even the original author of ANT, James Duncan Davidson, meant "Another Neat Tool".

Ant is easy!

The hard part is how to make a very complicated diversified system work very simple and elegant. Knowledge about ant is not enough, you need an elegant and simple design, you need great naming convention, you need to optimize the code reusability and flexibility, you need a least maintenance system...

Then it is not easy now ...

• Download the most recent version of ant from Apache; unzip it some where on your machine.
• Install j2sdk 1.4 or above.
• Set JAVA_HOME and ANT_HOME
• Put %JAVA_HOME%/bin;%ANT_HOME%/bin on your Path. Use ${JAVA_HOME}/bin:${ANT_HOME}/bin on UNIX. Yes, you can use forward slash on windows.
• Write a "Hello world" build.xml

              <project name="hello" default="say.hello" basedir="." >
                <property name="hello.msg" value="Hello, World!" />
                <target name="say.hello" >
                  <echo>${hello.msg}</echo>
                </target>
              </project>
            

• Type ant in the directory your build.xml located.
• You are ready to go!!!!

1. You should not use implicit fileset, which is deprecated. You should use nested fileset.
2. If dir does not exist, the build will fail, period!
3. If you are not sure, use a upper level dir, which exists for sure. See the following fileset.

  <delete>
    <fileset dir="${upperdir.which.exists}">
      <include name="${classes.dir}/*.class" />
    </fileset>
  </delete>
  

  <path id="build.classpath">
    <fileset dir="${build.lib}" includes="**/*.jar"/> 
    <fileset dir="${build.classes}" /> 
  </path>
 
  <target....>
    <javac ....>
      <classpath refid="build.classpath" />
    </java>
  </target>
 
  <target....>
    <java ....>
      <classpath refid="build.classpath" />
    </java>
  </target>
  

Store your password in your ${user.home}/prj.properties
pswd=yourrealpassword
In your include directory master prj.properties
pswd=password
In your build-common.xml read properties files in this order

1. The commandline will prevail, if you use it: ant -Dpswd=newpassword
2. ${user.home}/prj.properties (personal)
3. yourprojectdir/prj.properties (project team wise)
4. your_master_include_directory/prj.properties (universal)

Problem solved!

    <taskdef resource="net/sf/antcontrib/antcontrib.properties" />

Believe me or not? Forward slash works on windows in all ant or java code. It also works in windows environment variables. It does not work in cmd (dos) window before XP. It also works in XP dos window now!

<fileset id="fs1" dir="t1" includes="**/*.java"/>
<property name="f1.contents" refid="fs1"/>
<echo>f1.contents=${f1.contents}</echo>

  <target name="run" depends="some.target,some.other.target">

    <java classname="${run.class}" fork="yes">
      <classpath>
        <path refid="classpath" />
      </classpath>

      <jvmarg line="${debug.jvmargs}" />
      <jvmarg line="${my.jvmargs}" />
      <jvmarg value="-Dname=${name}" />
      <jvmarg line="${run.jvmargs}" />
      <arg line="${run.args}" />
    </java>
  </target>

• Do an echo on where you have doubt. You will find out what is the problem easily. Just like the old c printf() or Java System.println()
• Use project.log("msg") in your javascript or custom ant task
• Run Ant with -verbose, or even -debug, to get more information on what it is doing, and where. However, you might be tired with that pretty soon, since it give you too much information.

ExecTask compile = (ExecTask)project.createTask("exec");

• You don't need to unzip the files from archive to put into your destination jar/ear/war files.
• You can use zipfileset in your jar/war/ear task to extract files from old archive to different directory in your new archive.
• You also can use zipfileset in your jar/war/ear task to send files from local directory to different directory in your new archive.

  <jar destfile="${dest}/my.jar">
    <zipfileset src="old_archive.zip" includes="**/*.properties" prefix="dir_in_new_archive/prop"/>
    <zipfileset dir="curr_dir/abc" prefix="new_dir_in_archive/xyz"/>
  </jar>
    

• You changed the system time
• I had the same problem before, I checked out files from cvs to windows, and transfer them to a unix machine, somehow, I got huge amount of such warnings because the system timing issue.
• If you transfer files from Australia/China/India to the United States, you will get the problem too. True enough, I did and met the problem once.

<include name="a,b,c"/>

<include name="**/a,**/b,**/c"/>

<exclude name="**/*.*"/> 

1. Don't define java.home by yourself. Ant uses an internal one derived from your environment var JAVA_HOME. It is immutable.
2. I do the followings:
   • In my build.properties (read first)
     jdk13.bin=${tools.home}/jdk1.3.1_13/bin
     jdk14.bin=${tools.home}/j2sdk1.4.2_08/bin/
   • In my master properties file (read last), set default
     javac.location=${jdk13.bin}
   • In my prj.properties, if I need to use 1.4
     javac.location=${jdk14.bin}
   • in my javac task
     executable="${javac.location}/javac.exe"

  <compilerarg value="-Xlint"/>
  <!-- or -->
  <compilerarg value="-Xlint:unchecked"/>

    <xslt style="${xslfile}" in="${infile}" out="${outfile}" >
      <classpath>
        <fileset dir="${xml.home}/bin" 
          includes="*.jar" />
      </classpath>
    </xslt>

• Since target if/unless all depend on some property is defined or not, you can use condition to define different NEW properties, which in turn depends on your ant property values. This makes your ant script very flexible, but a little hard to read.
• Ant-contrib has <if> <switch> tasks for you to use.
• Ant-contrib also has <propertyregex> which can make very complicate decisions.

 
  <property file="${antutil.includes}/${os.name}-${os.arch}.properties" />

TimedBufferedReader.java

package setup;

import java.io.Reader;
import java.io.BufferedReader;
import java.io.IOException;

/**
 * Provides a BufferedReader with a readLine method that
 * blocks for only a specified number of seconds. If no
 * input is read in that time, a specified default
 * string is returned. Otherwise, the input read is returned.
 * Thanks to Stefan Reich 
 * for suggesting this implementation.
 * @author: Anthony J. Young-Garner
 * @author: Roseanne Zhang made improvement.
 */

public class TimedBufferedReader extends BufferedReader 
{
  private int    timeout    = 60; // 1 minute
  private String defaultStr = "";
    	  	
  /**
   * TimedBufferedReader constructor.
   * @param in Reader
   */
  TimedBufferedReader(Reader in) 
  {
    super(in);
  }

  /**
   * TimedBufferedReader constructor.
   * @param in Reader
   * @param sz int Size of the input buffer.
   */
  TimedBufferedReader(Reader in, int sz) 
  {
    super(in, sz);
  }

  /**
   * Sets number of seconds to block for input.
   * @param seconds int
   */
  public void setTimeout(int timeout) 
  {
    this.timeout=timeout;
  }

  /**
   * Sets defaultStr to use if no input is read.
   * @param str String
   */
  public void setDefaultStr(String str) 
  {
    defaultStr = str;
  }
    	  
  /**
   * We use ms internally
   * @return String
   */
  public String readLine() throws IOException 
  {
    int waitms = timeout*1000;
    int ms     = 0;
    while (!this.ready()) 
    {
      try 
      { 
        Thread.currentThread().sleep(10);
        ms += 10;
      }
      catch (InterruptedException e) 
      { 
        break; 
      }
      if (ms >= waitms) 
      {
      	return defaultStr;
      }
    }
    return super.readLine();
  }
}

  Dev
    |_src
    |  |_com
    |     |_mycom
    |        |_mypkg
    |           |_A.java
    |_test
       |_src
         |_com
            |_mycom
               |_mypkg
                  |_ATest.java

• Quilt here
• Copied from Quilt site: Quilt is a Java software development tool that measures coverage , the extent to which unit testing exercises the software under test. It is optimized for use with the JUnit unit test package, the Ant Java build facility, and the Maven project management toolkit.
• Interesting!!

  We wrote something similar to the functionality of quilt long time ago, when I was working in a Microsoft Solution Provider shop. We actually could tell how QA did their job. However, it was considered spying on QA, and for keeping the reasonable relationship between development and QA, we were forced to take them out.

  It would be better if it were a third party product, in my case.

• Took a look, we 'd be better off not to use it. The reasons are:
  1. It is stale, it stopped developing in 2003.
  2. It is dangerous, since it alters the bitecode.

lang=en
lang=cn 
lang=any other supported languages such as Spanish, etc.

/* @cn.comment.start@
String abc="??";
@cn.comment.end@ */

/* @en.comment.start@
String abc="Source code";
@en.comment.end@ */

// More languages here.

1. When we copy the code to the place for build (compile), the replacement is done automatically by ant copy task. Build games in different languages became as easy as switching one word in the build.properties.
2. One more thing is wonderful here. It is way better than use "if else or switch case statements". since the byte code is much smaller. It is especially important when you are building games on mobile devices.
3. We only need one code base instead of many, which made code maintenance a lot simpler, less headache!!!

By the way, I did all my native build by myself on 4 different operating systems. It is quite hack of work. You basically need to know how to do it without ant, then put them in ant to automate the process. Even I've not used ant-contrib cc task yet, but from rough look at the doc, I guess what I said would be still true.

How did I handle it?

I had a build/tmp/src directory, before compiling, I copied the source code need to compile to that directory. To mainstream developer, copying mainstream src was enough, then compile. To sandbox developer, copying mainstream src first, then copying the sandbox/src second, and set overwrite="true", very important, otherwise, copy task copies according to timestamps.

You javac from build/tmp/src to build/classes. In this way, your problem would be solved.

Actually, my case was way more complicated then, I even wrote my own copy task which called CopyWithDependencies. Of course, this is out of the range of our discussion here... Writing it down might help you think further...

• ant source code
• ant javadoc, when you download the source code, the javadoc is included.
• default.properties under ant source code