Basics of using Java Automation tools Ant Tutorial _java

What is ANT?
Apache Ant is a Java-based build tool. According to the original founder James Duncan Davidson, the name of the tool is the initials of the another neat tool (another neat tool).

Ant's Role:
build tools are used in software development to convert source code and other input files into executable files (and may also be converted to an installable product image form). As the process of application generation becomes more complex, it becomes even more important to ensure that the exact same build steps are used during each build, with as much automation as possible to produce consistent build versions in a timely fashion.

Ant's Advantages:
Ant is a Java-based build tool. In theory, it is somewhat similar to make in (Unix) C, but does not have a defect of make.　　The latest version is: Ant 1.8.4. Now that we have make, Gnumake, NMAKE, jam, and other build tools, why do we need a new build tool? Because Ant's original author developed software on a variety of (hardware) platforms, the limitations and inconveniences of these tools cannot be tolerated. Tools like make are essentially based on the shell (language): They compute dependencies, and then execute commands (these commands are not much different from the commands you've tapped on the command line). This means that you can easily extend the tool by using the OS-specific or writing a new (command) program, but it also means that you limit yourself to a particular OS, or to a particular OS type, such as UNIX.
Ant is different. Unlike an extended pattern based on a shell command, Ant expands with Java classes. (users) Do not have to write shell commands, which are xml-based, and can execute various tasks by invoking the target tree. Each task is run by an object that implements a specific task interface.
Ant defines a dependency between makefile, which uses a Cross-platform Java class. With ant, you can write a single build file that operates consistently on any Java platform (because Ant itself is implemented in the Java language), which is the biggest advantage of ant

Analysis of ant generation files:
Ant does not define its own custom syntax; instead, its makefile is written in XML. There is a set of predefined XML elements that ant can understand, and new elements can be defined to extend ANT's functionality. Each build file consists of a single project element that contains one or more target elements. A target (target) is a defined step in the build process that performs any number of operations, such as compiling a set of source files. And the operations themselves are performed by other specialized task tags and then these tasks are grouped into each target element as needed. All the actions necessary for a build process can be placed in a single target element, but that reduces flexibility. It is often preferable to divide those operations into logical build steps, each of which is contained within its own target element. This allows you to perform a separate part of the overall build process, but does not necessarily perform other parts.
For example, by calling only certain targets, you can compile the source code for your project without having to create an installable project file
The top-level project element needs to contain a default attribute that specifies the target to be executed if the target is not specified when Ant is invoked. You then need to use the target element to define the goal itself.

The following is a basic build file:

<?xml version= "1.0"?> 
 <project default= "init" > 
 <target name= "init" > 
  </target> 
</project> 

Ant Basic Usage:
1. Configure Environment variables:
ant_home:c:\ant-1.8-----> Ant Installation/Decompression directory path
Path Append: C:\ant-1.8\bin------>ant Bin directory path
2. Confirm that the environment variable configuration is successful
Open the cmd window, and then enter the command: Ant:
See the following display:

Because the ant build requires a default Build.xml file, it is like a hint that the ant environment has been configured successfully.

3. Use ant to create a folder named HelloWorld:
First you need to edit build.xml:

<?xml version= "1.0"?> 
 <project default= "init" > 
 <target name= "init" > 
  <span style= " Color: #FF0000; ><mkdir dir= "HelloWorld" ></span> 
 </target> 
</project> 

Then switch to the directory where the Build.xml file resides, enter Ant, and create the folder if you have the following prompts:
(init part corresponds to log output)

4. You can also use ant to create a multilevel nested file directory
You only need to make modifications in the Build.xml file:

<?xml version= "1.0"?> 
 <project default= "init" > 
 <target name= "init" > 
  <span style= "Color: #FF0000;" > <mkdir dir= "helloworld\a\b\c"/></span> 
 </target> 
</project> 

5. Delete the multilevel directory as above:

<?xml version= "1.0"?> 
 <project default= "init" > 
 <target name= "init" > 
  <span style= " Color: #FF0000; ><delete dir= "HelloWorld"/></span> 
 </target> 
</project> 

Note: The path here is only to enter the top-level directory path, which is the strength of the ant tool:
Java If you want to delete a directory, unless the directory is empty before you can delete, or you will be gradually deleted.
Using the Ant tool, you can delete folders that contain subdirectories directly.

Look at one more example XML file:

<?xml version= "1.0"?> 
<project default= "Init" name= "project" > 
<description> 
A Simple project introducing the "use of" descriptive tags in Ant build files. 
</description> 
<!--XML Comments can also be used--> 
<target name= "Init" description= " Initialize Argon Database "> 
<!--perform initialization steps here--> 
</target> 

As you can see, XML annotations can be used throughout the build file to improve clarity. Also, ANT defines its own description elements and description attributes that can be used to provide more structured annotations.

Ant Properties:
the properties in Ant are similar to variables in the programming language, and they all have names and values. However, unlike the usual variables, the properties in Ant cannot be changed once they are set, and they are immutable, just like String objects in the Java language. This may seem restrictive at first, but this is to follow Ant's simple principle: After all, it is a build tool, not a programming language. If you try to give an existing property a new value, it will not be treated as an error, but the property will still retain its existing value

Define and use attributes:

<property name= "Metal" value= "beryllium"/>

To refer to this property in other parts of the makefile, use the following syntax:

Copy Code code as follows:

${metal}

For example, to use such a value, it is part of the value of another property, and the label is written as follows

<property name= "Metal-database" value= "${metal}.db"/> 

Location Properties:
properties are often used to refer to files or directories on a file system, but for platforms that use different path delimiters (for example,/and \), this may cause problems across different platforms. Ant's Location property is specifically designed to include a file system path in a platform-independent fashion. Use location to replace value as follows:

<property name= "Database-file" location= "archive/databases/${metal}.db"/>

The path-delimited character used for the Location property is converted to the correct format for the current platform, and because the file name is relative, it is considered to be relative to the base directory of the project. We can also easily write as follows:

<property name= "Database-file" location= "archive\databases\${metal}.db"/>

The two versions of this label will have the same behavior on different platforms.

To define a dependency relationship:
building a project typically takes many steps--for example, to compile the source code first and then package it as a Java archive
(Java Archive File,jar). Many of these steps have well-defined sequences-for example, you cannot package class files until the compiler generates class files from source code. Unlike specifying target in order, ANT uses a more flexible approach to defining dependencies. Each goal is defined based on all other goals that must be completed before it can be executed. This is implemented using the depends attribute of the target element.

<target name= "init"/> 
<target name= "preprocess" depends= "init"/>
<target "Name=" depends= "init,preprocess"/> <target name= "package" depends= "compile"/>

This approach allows you to perform the build process at any stage of the project, and Ant will first execute the defined prerequisites. In the above example, if ANT completes the compile step, it will determine the two goals that need to be executed first for Init and preprocess. The init target is not dependent on any other target, so it will be executed first. Ant then examines the preprocesstarget and finds that it relies on the init target, and since the latter has been executed, Ant does not execute it again, thus starting to execute the preprocess target. Finally, you can perform the compile task itself.
Note the order in which the target appears in the makefile is not important: the execution order is uniquely determined by the depends attribute.