Ant installation and configuration

xiaoxiao2021-03-05  22

Summary: Ant is a Java-based automation scripting engine, the script format is XML. In addition to making Java compilation related tasks, Ant can also achieve a number of applications in a plugin.

The basic concept of Ant: Installation of Ant: Unpack, set the path Ant: 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 Print this script Help information (Default) Task 2: Clean <- Init Clear 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. For example, add the following to / etc / profile on GNU / Linux: Export Ant_Home = / Home / ANTEXPORT JAVA_HOME = / USR / Java /j2sdk1.4.1export path = $ PATH: $ java_home / bin: $ ant_home / bin After performing Ant, if you do not specify the configuration file Ant will save the build.xml this configuration file, and perform tasks according to the configuration file, Task settings can point to the most common tasks, such as: Build, or pointing to print help: usage, telling users that there are those script options to use.

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

JDOM's build.xml:

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 Tasks: JUnit Test Code Style Check Tasks: Checkstyle, Jalopy and other email alerts: You can send the output warning of these tasks to the developed user list, this task can be set automatically.

转载请注明原文地址:https://www.9cbs.com/read-37770.html

New Post(0)