Copyright Notice: You can reprint anything, please be sure to indicate the original source and author information and this statement by hyperlink.
http://www.chedong.com/tech/ant.html
Keywords: Ant Build.xml Javac
abstract:
Ant is a Java-based automation scripting engine with an XML in the script. In addition to making Java compilation related tasks, Ant can also achieve a number of applications in a plugin.
Basic concept of Ant:
Ant installation: Unpack, set the path
Ant's use: The best study is just a simple and practical example start ...
Basic concept of Ant: Makefile of Java
When a code project is big, each time you recompile, package, test, etc., it will become very complicated and repeated, so the Make script in the C language has completed the batch of these work. Application in Java is a platform-independent. Of course, these batch tasks are not completed with platform-related Make scripts. Ant itself is such a process scripting engine for automated calling programs to complete project compilation, packaging, test, etc. . In addition to Java-based platforms, the format of the script is based on XML, which is better to maintain than the Make script.
A series of tasks (Target) is set in each Ant script (default build.xml): For example, there may be the following tasks for a general project.
Task 1: Usage Prints Help Information (Default)
Task 2: Clean <- Init Clearing Initialization Environment
Task 3: Javadoc <- Build <- Init Generate Javadoc
Task 4: Jar <- build <- init generates JAR
Task 5: All <- Jar Javadoc <- Build <- init completed all tasks: Jar Javadoc
There is often a dependency between multiple tasks: such as this, depending on the compilation task, while compiling tasks depending on the entire environment initialization task (Init).
Note: I see that the names in the Ant scripts in many projects are basically consistent, such as compilation. BUILD or Compile; package general call JAR or WAR; generate documents generally named javadoc or javadocs; Perform all task all. In each task, Ant will call some external applications according to the configuration and configure the corresponding parameters. Although Ant can call external applications very rich, it is actually 2,3: such as Javac Javadoc Jar et al.
Ant installation
After unpacking, add the path to the bin pointing to Ant in the system executable path, such as adding the following configuration to / etc / profile on GNU / Linux:
Export Ant_Home = / Home / Ant
Export java_home = / usr / java / j2sdk1.4.1
Export Path = $ PATH: $ java_home / bin: $ ant_home / bin
After this is executed, if you do not specify the configuration file Ant to save the build.xml this configuration file, and the default task settings can point to the most common task, such as: build, or point to print help information. : USAGE tells users that there are those script options that can be used.
Ant use
The best learning process is to understand the build.xml script in the Open source project, and then simplify into a simpler, Ant and Apache projects on Ant and Apache: Simple and easy to use, and adaptability is very Strong, because the establishment of these projects is often derived from the most direct needs of developers. The following is an example of a Weblucene application: Modify build.xml from JDOM:
Destdir = "$ {build.dest}" Debug = "$ {debug}" Optimize = "$ {Optimize}"> Basedir = "$ {build.dest}" INCLUDES = "**" /> SourcePath = "$ {build.src}" destdir = "$ {build.javadocs}" Author = "True" Version = "True" Use = "true" SplitIndex = "True" WindowTitle = "$ {name} api" DOCTITE = "$ {name}"> Default tasks: USAGE prints help documents, tells those task options: available with Build, Jar, Javadoc, and Clean. Initializing environment variable: init All tasks are based on the initialization of some basic environment variables, which is the foundation of subsequent other tasks. During the initialization process, there is 2 points comparison to make it easy to set: 1 In addition to using the default Property set up the Java source path and output path, the settings in an external build.properties file are referenced. Such a simple configuration user can understand the build.properties, after all, XML is more readable than the property file of Key Value. With build.properties, you can easily liberate from compiled details. 2 ClassPath Settings: Used in it: It is equivalent to setting: classpath = / path / to / resin / lib / jsdk23.jar; /path/to/project/lib/*.jar; Document copy: prepare-src Create a temporary SRC storage directory and output directory. Compilation task: Build ClassPATH environment at compile time Find a reference to a PATH object Package task: jar The .jar files written to the Package Generation Project Basedir = "$ {build.dest}" INCLUDES = "**" /> Generate a Javadoc documentation task: javadoc SourcePath = "$ {build.src}" destdir = "$ {build.javadocs}" Author = "True" Version = "True" Use = "true" SplitIndex = "True" WindowTitle = "$ {name} api" DOCTITE = "$ {name}"> Empty temporary compilation file: Clean Todo: More tasks / extensions: (sample) Test task: JUnit Test Code Style Check Task: Checkstyle, Jalopy, etc. Email alert task: You can send the output warning of these tasks to the developed user list, which can be set automatically every day.
