![\"learn-apache-ant-from-experts\"](\"http:\/\/www.scmgalaxy.com\/tutorials\/wp-content\/uploads\/2009\/01\/learn-apache-ant.png\")
<\/p>\n<\/p>\n
Apache Ant: Learn Apache Ant from IBM Experts <\/strong><\/span><\/p>\n Section 1. Getting started\u00a0<\/span><\/u><\/strong><\/span><\/p>\n \u00a0\u00a0<\/strong> Section 2. Ant basics<\/strong><\/span><\/u><\/p>\n Ant basics introduction<\/strong> Note that this is well-formed XML, with an XML declaration specifying the version of XML being used (this is not currently required by Ant, but it is good practice), and with every element being properly closed. It is also possible to open and close an element in one go. So, instead of the separate start and end tags for the target element above, we could have written it as follows:<\/p>\n This more concise form can be clearer when an element doesn’t have any enclosed content.<\/span><\/p>\n Adding descriptions<\/strong> A simple project introducing the use of descriptive tags in Ant build files.<\/p>\n As you can see, XML comments can be used throughout build files to improve clarity. Also, Ant defines its own description element and description attribute, which can be used to provide more structured annotations.<\/p>\n Properties<\/strong> To refer to this property in other parts of the build file, you would use this syntax: ${metal} For example, to use the value of one property as part of the value of another, you would write a tag that looks like this:<\/span><\/p>\n <\/p>\n There are number of predefined properties in Ant. Firstly, all of the system properties set by the Java environment used to run Ant are available as Ant properties, such as ${user.home}. In addition to these, Ant defines a small set of its own properties, including ${ant.version}, which contains the version of Ant, and ${basedir}, which is the absolute path of the project’s directory (as defined by the directory containing the build file, or by the optional basedir attribute of the project element). Properties are often used to refer to files and directories on the filesystem, but this could cause problems across different platforms with different path separator characters ( \/ versus \\, for example). Ant’s location attribute is specifically designed to hold filesystem paths in a platform-neutral way. You would use location in place of value like so: <\/p>\n The path separator characters used for the location attribute are converted to the correct ones for the current platform; and, as the filename is relative, it is taken to be relative to the project’s base directory. We could just as easily have written this instead:<\/span><\/p>\n <\/p>\n Both versions of this tag will behave in the same fashion across different platforms. The only thing to avoid if portability is required is DOS-style drive letters in Defining dependencies<\/strong> <\/p>\n This approach allows you to request a build of any stage of the project; Ant will execute the defined prerequisite stages first. In the example above, if you ask Ant to developerWorks\u00ae ibm.com\/developerWorks complete the compile step, it determines that the targets init and preprocess need to be executed first. The init target doesn’t depend on anything, so that will <\/p>\n Section 3. Running Ant<\/strong><\/span><\/u><\/p>\n Running Ant introduction<\/strong><\/span><\/p>\n The Apache Ant tool can be invoked in various ways. On its own, Ant comes in command-line form, and is usually invoked from a UNIX or Linux shell prompt or a Windows command prompt, with the build files being written using your text editor of choice. This is fine if the project to be built is being developed in this way, but many find IDEs more convenient. Most of these offer some level of support for Ant, so at a minimum Ant builds can be invoked without the hassle of having to leave the IDE to perform command-line operations.<\/span><\/p>\n In this section, we’ll see how to use Ant from the command line, and learn some useful command-line options. Then we’ll take a brief tour of the Ant support offered by the open source Eclipse platform. (You should be at least passingly familiar with Eclipse in order to get the most out of those panels.)<\/span><\/p>\n Running Ant from the command line<\/strong><\/span><\/p>\n Invoking Ant from your command prompt can be as simple as just typing ant on its own. If you do so, Ant uses the default build file; the default target specified in that build file is the one that Ant attempts to build. It is also possible to specify a number of command-line options, followed by any number of build targets, and Ant will build each of these targets in order, resolving any dependencies along the way.<\/span><\/p>\n Here is some typical output from a simple Ant build executed from the command line:<\/span><\/p>\n Buildfile: build.xml<\/span><\/p>\n init: compile: dist: BUILD SUCCESSFUL We’ll see just what all that means as we move on through the tutorial.<\/p>\n Command-line options<\/strong><\/span><\/p>\n Just as the make tool looks for a build file with the name makefile by default, Ant looks for a file with the name build.xml. Therefore, if your build file uses this name, you don’t need to specify it on the command line. Naturally, it is sometimes convenient to have build files with other names, in which case you need to use the -buildfile arguments to Ant ( -f is the abbreviated version).<\/span><\/p>\n Another useful option is -D, which is used to set properties that can then be used in the build file. This is very useful for configuring the build you want to initiate in some way. For example, to set the name property to a particular value, you would use an option that looks something like this:<\/span><\/p>\n -Dmetal=beryllium IDE integration<\/strong><\/span><\/p>\n Due to Ant’s popularity, most modern IDEs now have integrated support for it, and many others offer support for it in plugins. The list of supported environments includes the JEdit and Jext editors, Borland JBuilder, IntelliJ IDEA, the Java Development Environment for Emacs (JDEE), NetBeans IDE, Eclipse, and WebSphere (R) Studio Application Developer.<\/span><\/p>\n Eclipse support for Ant<\/strong><\/span><\/p>\n The open source Eclipse project offers a great deal of support for Ant. The core of this support is Eclipse’s Ant editor, which features syntax highlighting. The editor is illustrated below:<\/span><\/p>\n <<<<<<<<<<<<<<<<< This editor provides content assistance — for example, typing tag, and a short explanation of that task. <\/span><\/p>\n You can also see an outline view that shows the structure of the build file and provides a quick way of navigating through the file. There is also an Ant view that allows targets to be built from a number of different Ant files.<\/span><\/p>\n Running Ant builds from within Eclipse<\/strong><\/span><\/p>\n Files named build.xml are identified and decorated in Eclipse’s navigator view with an Ant icon. (See File associations in Eclipse if your build file has a different filename.) Right-clicking these files provides a Run Ant… menu option that opens a dialog like the one shown below:<\/span><\/p>\n <<<<<<<<<<<<<<<<< All of the targets from the build file are shown, with the defaults selected. After you’ve decided whether or not to change the default targets, press the Run button to launch Ant. Eclipse will switch to the Console view to show the output, as illustrated below. Errors are shown in a different color, and you can click on task names in the output to jump to the corresponding invocation in the build file.<\/span><\/p>\n <<<<<<<<<<<<<<<<< File associations in Eclipse<\/strong><\/span><\/p>\n By default, Eclipse only uses the Ant editor on files named build.xml, but you can easily configure the editor to recognize files with other names. Select Window=>Preferences from the menu, then expand the Workbench group, and select the File Associations preference page. Then add a new file type for the desired filenames. You could, for example, add a new file type for all files named mybuild.xml. You could even use *.xml if you want to do the same for all files with an .xml suffix (except for specific filenames, such as plugin.xml, which in Eclipse override the wildcard specifications). Finally, add an associated editor for this new file type, and select Ant editor from the editor selection list, as shown below:<\/span><\/p>\n <<<<<<<<<<<<<<<<< <\/p>\n Section 4. Building a simple Java project<\/strong><\/span><\/u><\/p>\n Building a simple Java project introduction<\/strong><\/span><\/p>\n Now that we have seen the format of Ant build files, and learned how to define properties and dependencies and how to run Ant, we are ready to construct a build environment for a basic Java project. This will involve learning the Ant tasks for compiling source code and assembling JAR files. As Ant is primarily aimed at building Java applications, it should come as no surprise that it has excellent built-in support for invoking the javac compiler and other Java-related tasks. Here’s how to write a task that compiles some Java code:<\/span><\/p>\n <\/p>\n This tag looks for all files ending in .java in the src directory and invokes the javac compiler on them, generating the classfiles in the same directory. Of course, it is usually cleaner to put the classfiles under a separate directory structure; you can have Ant do this by adding a destdir attribute. Other useful attributes:<\/p>\n classpath: Equivalent to the -classpath option on javac. Like Ant, the javac compiler is itself implemented in the Java language. This is used to good advantage by the javac task in Ant, because it usually invokes the compiler classes in the same Java virtual machine (JVM) in which Ant itself is running in. Other build tools would typically need to launch a new javac process each time Java code needed to be compiled, which would in turn require a new JVM instance. But with Ant, only a single JVM instance is required, both to run Ant itself and to perform all of the required compilation tasks (along with other related tasks, such as manipulating JAR files). This is a far more efficient use of resources and can lead to greatly improved build times. Compiler options<\/strong><\/span><\/p>\n As we saw in the previous section, the default behavior of the Ant javac task is to invoke the standard compiler of whichever JVM is being used to run Ant itself, and to invoke that compiler in-process (that is, without launching a separate JVM). However, there may be times when you want the compiler to be invoked separately — when you wish to specify certain memory options to the compiler, for instance, or when you need to use a different level of the compiler. To achieve this, simply set javac ‘s fork attribute to true, like this:<\/span><\/p>\n <\/p>\n And if you want to specify a different javac executable, and pass a maximum memory setting to it, you would do something like this:<\/p>\n memoryMaximumSize=”128m”\/> You can even configure Ant to use a different compiler altogether. Supported compilers include the open source Jikes compiler and the GCJ compiler from the GNU Compiler Collection (GCC). (See Resources for information on these two compilers.) These can be specified in two ways: either by setting the build.compiler property, which will apply to all uses of the javac task, or by setting the compiler attribute in each javac task as required. Creating a JAR file<\/strong><\/span><\/p>\n After Java source files have been compiled, the resulting classfiles are typically packaged into a JAR file, which is similar to a zip archive. Every JAR file contains a manifest file that can specify properties of the JAR file.<\/span><\/p>\n Here’s a simple use of the jar task in Ant:<\/span><\/p>\n <\/p>\n This creates a new JAR file called package.jar and adds all the files in the classes directory to it (JAR files can contain any type of file, not just classfiles). In this case, no manifest file was specified, so Ant will provide a basic one.<\/p>\n The manifest attribute allows you to specify a file to use as the manifest for the JAR file. The contents of a manifest file could also be specified within the build file using the manifest task. This task can write a manifest file to the filesystem, or can actually be nested inside the jar task so that the manifest file and JAR file are created all in one go. For example:<\/span><\/p>\n <\/p>\n <\/p>\n Time-stamping builds<\/strong><\/span><\/p>\n It is often desirable in a build environment to use the current time and date to mark the output of a build in some way, in order to record when it was built. This might involve editing a file to insert a string to indicate the date and time, or incorporating this information into the filename of the JAR or zip file.<\/span><\/p>\n This need is addressed by the simple but very useful tstamp task. This task is typically called at the start of a build, such as in an init target. No attributes are required, so just is sufficient is many cases.<\/span><\/p>\n The tstamp task doesn’t produce any output; instead, it sets three Ant properties based on the current system time and date. Here are the properties that tstamp sets, an explanation for each, and examples of what they might be set to:<\/span><\/p>\n Property Explanation Example For example, in the previous section we created a JAR file as follows:<\/span><\/p>\n <\/p>\n After having called the tstamp task, we could name the JAR file according to the date, like this:<\/p>\n <\/p>\n So, if this task were invoked on December 17, 2003, the JAR file would be named package-20031217.jar.<\/p>\n The tstamp task can also be configured to set different properties, apply an offset before or after the current time, or format the strings differently. All of this is done using a nested format element, as follows:<\/span><\/p>\n <\/p>\n The listing above sets the OFFSET_TIME property to a time in hours, minutes, and seconds that is 10 minutes after the current time.<\/span><\/p>\n The characters used to define the format strings are the same as those defined by the java.text.SimpleDateFormat class. <\/span><\/p>\n Putting it all together<\/strong><\/span><\/p>\n The previous sections have given us enough knowledge to build a simple Java project. We will now assemble the code snippets into a complete build file that compiles all the source code under a src directory, puts the resulting classfiles under a build directory, and then packages everything up into a JAR file in a dist directory, ready for distribution. In order to try this out for yourself, all you need is a src directory containing one or more Java source code files — anything from a simple “Hello World” program to a large number of source files from an existing project. If you need to add JAR files or anything else to the Java classpath in order to successfully compile your source code, simply add a classpath attribute for it in the javac task.<\/span><\/p>\n The build file looks like this:<\/span><\/p>\n <\/p>\n A simple Java project<\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n And here is some sample output from a build that was run with that file (yours may vary, depending on the contents of your src directory):<\/p>\n Buildfile: build.xml<\/span><\/p>\n init: compile: dist: BUILD SUCCESSFULs <\/p>\n Notice that the JAR file is named according to the current date, and that a manifest entry is set for the main class of the application, so that it can be launched directly with a command along the lines of java -jar package-20031217.jar. We also create a JAR file consisting of just the source code of the project.<\/span><\/p>\n <\/p>\n Section 5. Filesystem operations<\/strong><\/span><\/u><\/p>\n Filesystem operations introduction<\/strong><\/span><\/p>\n We’ve learned enough about Ant now to be able to build a basic Java project, but naturally real-world projects are rarely as simple as our example. In the next few sections, we’ll look some of Ant’s numerous additional capabilities and the situations in which they can be used.<\/span><\/p>\n In this section, we’ll see how to perform common file operations, such as creating directories and unpacking files. One of the good features of Ant is that the tasks to perform these operations generally behave the same on all platforms. <\/span><\/p>\n Creating and deleting directories<\/strong><\/span><\/p>\n One of the most basic filesystem operations is the creation of a directory or folder. The Ant task for this is called mkdir, and it is unsurprisingly very similar to the Windows and UNIX\/Linux commands of the same name:<\/span><\/p>\n <\/p>\n Note first the use of \/ as the directory separator, which is the convention for UNIX and Linux platforms. You might think that this isn’t very platform neutral, but Ant knows how to handle it, and will do the right thing for whichever platform it is running on, in the same way as we saw earlier when defining location-based properties. We could just as easily have used \\ instead, regardless of platform — Ant handles either form, or even a mixture of both.<\/p>\n Another useful feature of the mkdir task is its ability to create parent directories if they don’t exist already. Consider the listing above, and imagine that the archive directory exists, but not the metals directory. If you were using the underlying platform’s mkdir commands, you would need to first explicitly create the metals directory, and then create the zinc directory using a second invocation of the mkdir command. But the Ant task is smarter than this, and will create both directories in one go. Similarly, if the target directory already exists, the mkdir task will not complain, but will just assume that its work is already done, and do nothing.<\/span><\/p>\n Deleting directories is just as easy:<\/span><\/p>\n Copying and moving files and directories<\/strong><\/span><\/p>\n Making a copy of a file is simple in Ant. For example:<\/span><\/p>\n <\/p>\n You can also use move to perform a rename operation instead of copying the file:<\/p>\n <\/p>\n Another common filesystem operation is to copy or move a file into another directory. The Ant syntax for this is just as straightforward:<\/p>\n <\/p>\n <\/p>\n By default, Ant only outputs a summary of the move and copy operations it performs, including such information as the number of files it has moved or copied. If you wish to see more detailed information, including the names of the files involved, you can set the verbose attribute to true. In the previous section, we saw how to create a JAR file. The process is almost exactly the same for creating other archive files. Here is an Ant task that creates a zip file instead:<\/span><\/p>\n <\/p>\n The same syntax can also be used to create tar files. Files can also be compressed using the GZip and BZip2 tasks. For example:<\/p>\n <\/p>\n Uncompressing and extracting files is just as straightforward:<\/p>\n <\/p>\n The overwrite attribute can also be included to control the overwrite behavior. The default is to overwrite any existing files with matching entries from the archive being extracted. The related task names are untar, unjar, gunzip, and bunzip2.<\/p>\n Replacing tokens in files<\/strong><\/span><\/p>\n The final filesystem operation we will look at in this section is the replace task, which performs search and replace operations within files. The token attribute specifies the string to be searched for, and the value attribute specifies the new string that all occurrences of the token string should be replaced with. For example:<\/span><\/p>\n \u00a0<\/span><\/p>\n The replacement occurs in place, within the file itself. To provide more detailed output, set the summary attribute to true. This causes the task to output the number of occurrences of the token string that were found and replaced.<\/span><\/p>\n <\/p>\n Section 6. Extending Ant with custom tasks<\/strong><\/span><\/u><\/p>\n Extending Ant with custom tasks introduction<\/strong><\/span><\/p>\n As we’ve seen throughout the previous sections, Ant is very powerful, with a number of core tasks covering a broad set of functionality. There are a number of additional core tasks not covered here, plus a number of optional tasks providing a wide variety of additional functionality, as well as other tasks that are available as part of the Ant-Contrib project; finally, there are even more externally available tasks listed on the Apache Ant home page. Given all of this, it might seem unlikely that you’d ever need any other tasks, but the real power of Ant lies in its ease of extensibility. In fact, it is precisely this extensibility that has resulted in such a large number of additional tasks being developed.<\/span><\/p>\n There can be occasions when creating your own custom task is a good idea. For example, imagine that you have created a command-line tool to perform a particular operation; this tool might be a good candidate to be made available as an Ant task (particularly if the tool was written in the Java language, although this doesn’t have to be the case). Instead of having Ant call the tool externally using the exec task (which introduces dependencies and makes it harder to use your build file across different environments), you can incorporate it directly into the build file. The regular fileset and wildcard matching capabilities of Ant can also be made available to your custom task.<\/span><\/p>\n In this section, we’ll take a look at the construction of a simple custom task. This task will perform a sort operation on the lines of a file, and write the sorted set of lines out to a new file. <\/span><\/p>\n Creating a custom task<\/strong><\/span><\/p>\n To implement a simple custom task, all we need to do is extend the org.apache.tools.ant.Task class and override the execute() method. So, as a skeleton of our file sorter custom task, we have the following:<\/span><\/p>\n import org.apache.tools.ant.BuildException; public class FileSorter extends Task { Most tasks, core and custom alike, make use of attributes to control their behavior. For our simple task, we need an attribute to specify the file to be sorted, and another to specify the output file for the sorted contents. Let’s call these attributes file and tofile, respectively.<\/span><\/p>\n Ant makes it very easy to support attributes in custom tasks. We do this simply by implementing a method with a specifically formatted name that Ant can call with the values of the corresponding attribute specified in the build file. The name of the method needs to be set plus the name of the attribute, so in our case we need methods called setFile() and setTofile(). When Ant encounters an attribute setting in the build file, it looks for a method of the appropriate name, known as a setter method, in the associated task.<\/span><\/p>\n
\nWhat is this tutorial about?<\/strong>
\nIn this tutorial, you’ll learn about Ant, a build tool for Java TM projects. Ant has quickly become popular among Java developers because of its flexibility and ease of use, so you it owe it to yourself to find out more about it. You don’t need any prior experience with or knowledge of Ant before you proceed. We’ll first see the basic structure of Ant build files, and learn how to invoke the tool. We’ll walk through the steps involved in writing a build file for a simple Java project, and then look at some of Ant’s other useful functions, including filesystem operations and pattern matching. We’ll finish by writing our own Java class that extends Ant’s functionality. In the course of the tutorial, we’ll show you how to run Ant both from the command line and from within the open source Eclipse IDE. You don’t need both environments.<\/span><\/p>\n
\nIn this section, we’ll give you an overview of Ant’s capabilities and strengths, and discuss its history and rise in popularity. We then delve straight into the fundamentals of Ant by examining the basic structure of a minimal build file. We’ll also introduce the concepts of properties and dependencies. What is Ant? Apache Ant is a Java-based build tool. According to its original author, James
\nDuncan Davidson, the name is an acronym for another neat tool. Build tools are used in software development to transform source code and other input files into an executable form (and maybe into installable product images as well). As an application’s build process becomes more complex, it becomes increasingly important to ensure that precisely the same build steps are carried out
\nduring each build, with as much automation as possible, in order to produce consistent builds in a timely manner. Traditional projects in C or C++ often use the make tool for this purpose, where the build tasks are performed by invoking shell commands, and dependencies are defined between each of the build tasks so that they are always performed in the necessary order.
\nAnt is similar to make in that it defines dependencies between build tasks; however, instead of implementing build tasks using platform-specific shell commands, it uses cross-platform Java classes. With Ant, you can write a single build file that operates consistently on any Java platform (as Ant itself is implemented in the Java language); this is Ant’s greatest strength.
\nAnt’s other key strengths are its powerful simplicity and its ability to be seamlessly extended with custom capabilities. Hopefully, you will appreciate these strengths after completing the rest of this tutorial.
\nA little history<\/strong>
\nAnt started out as an internal component of Tomcat, the servlet container that is used in the reference implementation for the Java Servlet and JavaServer Pages (JSP) technologies. The Tomcat codebase was donated to the Apache Software Foundation; there, it became part of the Apache Jakarta project, which has a mission to produce open source, server-side solutions for the Java platform. The
\nusefulness of Ant was quickly recognized and its usage spread throughout the other Jakarta subprojects. Thus, it was made into a Jakarta subproject of its own, with the first independent release being made in July of 2000. Since then, Ant’s popularity has grown and grown. It has won numerous industry awards and become the de facto standard for building open source Java projects. In
\nNovember of 2002, this success was acknowledged by Ant’s promotion to a top-level Apache project. At the time of writing, the current stable release of Ant is 1.5.4, which supports all
\nJDK versions from 1.1 onwards. Beta versions of the next release, 1.6, are also available; these require JDK 1.2 or later. Planning is also underway for a future 2.0 release, which will involve a major rearchitecture. Ant 2.0 will feature improved consistency and enhanced functionality, whilst still retaining Ant’s core goals of simplicity, ease of understanding, and extensibility.
\nAnatomy of an Ant build file<\/strong>
\nAnt does not define its own custom syntax; instead, its build files are written in XML (see Resources ). There are a defined set of XML elements that Ant understands, and, as you’ll see in a later section, new elements can be defined to extend Ant’s capabilities. Every build file consists of a single top-level project element, which in turn contains one or more target elements. A target is a defined step in a build that performs any number of operations, such as compiling a set of source files. The operations themselves are performed by other specialized task tags, as we’ll see later. These tasks are then grouped together into target elements, as desired. All of the operations required for a build could be placed into a single target element, but that would reduce flexibility. It is usually preferable to split the operations into logical build steps, with each step contained in its own target element. This allows you to perform one individual part of the overall build without necessarily performing other parts. For instance, by only invoking certain targets, you could compile your project’s source code without creating an installable project image. The top-level project element needs to contain a default attribute that specifies the target to be executed if none is specified when Ant is invoked. Then the target itself needs to be defined, using the target element. Here is a minimal build file:<\/span><\/p>\n
\nThe build file we saw in the previous section is nice and concise, but it doesn’t say much about the actual project being built. There are a number of ways to make it more descriptive without changing the functionality. Here’s an example:<\/span><\/p>\n
\nProperties in Ant are like programming language variables in that they have a name and a value. However, unlike normal variables, properties in Ant cannot be changed once they have been set; they are immutable, like String objects in the Java language. This might seem restrictive at first, but it is in keeping with Ant’s philosophy of simplicity: after all, it is a build tool, not a programming language. If
\nyou do attempt to give an existing property a new value, this isn’t treated as an error, but the property does retain its existing value. (This behavior can be useful, as we’ll see.)
\nBased on the descriptive names of the elements and attributes seen so far, it should come as no surprise that the mechanism for setting properties in Ant looks like this:
\n<\/span><\/p>\n
\n<\/span><\/p>\n
\nfilenames. It is also more flexible to use relative path names instead of absolute ones where possible.<\/span><\/p>\n
\nBuilding a project generally requires a number of steps — first compiling source code and then packaging it into Java Archive Files (JARs) files, for example. (See Resources for more information on using JARs.) Many of these steps have a clearly defined order — for instance, you can’t package the classfiles until they have been generated by the compiler from the source code. Instead of specifying the targets in sequence order, Ant takes the more flexible approach of defining dependencies, just as make and similar build tools do. Each target is defined in terms of all the other
\ntargets that need to be completed before it can be performed. This is done using the depends attribute of the target element. For example:<\/span><\/p>\n
\nbe executed first. Then Ant will look at the preprocess target and find that it depends on the init target; because it has already run that, it doesn’t do so again, and executes the preprocess target. Finally, the compile task itself can be executed. Note that the order in which the targets appear in the build file is not important: it is only the depends attributes that determine execution order. <\/span><\/p>\n
\n[mkdir] Created dir: E:\\tutorials\\ant\\example\\build
\n[mkdir] Created dir: E:\\tutorials\\ant\\example\\dist<\/span><\/p>\n
\n[javac] Compiling 8 source files to E:\\tutorials\\ant\\example\\build<\/span><\/p>\n
\n[jar] Building jar: E:\\tutorials\\ant\\example\\dist\\example.jar<\/span><\/p>\n
\nTotal time: 2 seconds<\/span><\/p>\n
\nThis capability can be used to override initial property settings in the build file. As noted earlier, you cannot change the value of a property once it has been set. The -D flag sets a property before any information in the build file is read; because the assignment in the build file comes after this initial assignment, it therefore doesn’t change the value.<\/span><\/p>\n>>>>>>>>>>>>>>>>>>>><\/span><\/p>\n
>>>>>>>>>>>>>>>>>>>><\/span><\/p>\n
>>>>>>>>>>>>>>>>>>>><\/span><\/p>\n
>>>>>>>>>>>>>>>>>>>><\/span><\/p>\n
\nCompiling source code<\/strong><\/span><\/p>\n
\ndebug=”true”: Indicates to the compiler that the source files should be compiled with debug information.
\nAn important characteristic of the javac task is that it will only compile those source files that it believes it needs to. If a classfile already exists, and that classfile’s corresponding source file hasn’t been changed since the classfile was generated, then that source file won’t be recompiled. The output of the javac task shows the number of source files that were actually compiled. It is good practice to write a clean target that removes any generated classfiles from that target directory. This can then be used if you want to make sure that all of the source files are compiled. This behavior characterizes many of Ant’s tasks: If the task can determine that the requested operation doesn’t need to be performed, then it will be skipped.<\/span><\/p>\n
\n<\/span><\/p>\n
\n<\/span><\/p>\n
\n<\/span><\/p>\n
\nDSTAMP This is set to the current date, the default format being yyyymmdd 20031217
\nTSTAMP This is set to the current time, the default format being hhmm 1603
\nTODAY This is set to a string describing the current date, with the month written in full December 17 2003 <\/span><\/p>\n
\npattern=”HH:mm:ss”
\noffset=”10″ unit=”minute”\/><\/span><\/p>\n
\n[mkdir] Created dir: E:\\tutorial\\javaexample\\build
\n[mkdir] Created dir: E:\\tutorial\\javaexample\\dist<\/span><\/p>\n
\n[javac] Compiling 10 source files to E:\\tutorial\\javaexample\\build<\/span><\/p>\n
\n[jar] Building jar: E:\\tutorial\\javaexample\\dist\\package-20031217.jar
\n[jar] Building jar: E:\\tutorial\\javaexample\\dist\\package-src-20031217.jar<\/span><\/p>\n
\nTotal time: 5 seconds<\/span><\/p>\n
\nThis will delete the specified directory, along with any files and sub-directories it contains. Use the file attribute instead of dir to specify a single file to be deleted.<\/span><\/p>\n
\nCreating and unpacking zip and tar files<\/strong><\/p>\n
\nimport org.apache.tools.ant.Task;<\/span><\/p>\n
\n\/\/ The method executing the task
\npublic void execute() throws BuildException {}
\n}
\nNotice that the execute() method is declared to throw a BuildException. If anything goes wrong with our task, we throw this to signal the failure back to Ant.<\/span><\/p>\n