1, what is ant
ant is a build tool
2, what is the
concept of construction can be found everywhere, in terms of image, you have to take the code from somewhere, compile it, copy it to a place, etc., of course, not only With this, but mainly used to do this
3, the benefits of ant
cross-platform - because ant is implemented in java, it is easy to use across platforms - clearer syntax
than ant's brother make - the same as make More powerful
than -ant can do a lot of things, maybe you've used it for a long time, and you still don't know how many functions it can have.
When you develop some ant plugins yourself, you will find it more functional.
4, ant's brother make
ant does a lot of things, most of which were done by a man called make, but the objects are different, make is more used in c/c++, and ant is more used in Java. Of course this is not certain, but most people do.
First, build ant environment
To use ant, you must first build an ant environment, the steps are very simple:
1), install jdk, set JAVA_HOME, PATH, CLASS_PATH (these should be known to those who read this article)
2), download ant Address http://www.apache.org/ to find a version you like, or simply the latest version
3), unzip ant what you get is a compressed package, unzip it, and put it in a directory as simple as possible , for example D:\ant-1.6 While you don't have to, it's good to do so.
4), set ANT_HOME, add the bin directory under the ANT_HOME directory to the PATH (I set: ANT_HOME: D:\apache-ant-1.8.2, PATH:%ANT_HOME%\bin)
5), test your settings, Start-->Run-->cmd to enter the command line-->Type ant and press Enter, if you see
Buildfile: build.xml does not exist!
Build failed
, then congratulations, you have completed the ant settings
Second, experience ant
like every Every language has HelloWorld, the simplest application can make people feel Ant
1, first of all you need to know what you want to do, what I want to do now is:
write some programs,
compile them
, package it into a jar package
and put them in
Run them where they should be placed. For the
sake of simplicity, just write one program, that is, the HelloWorld.java program code is as follows:
package test.ant;
public class HelloWorld{
public static void main(String[] args){
System.out.println( "Hello world1");
}
};
2, in order to achieve the above purpose, you can manually use javac, copy, jar, java to complete, but consider if you have hundreds or thousands of classes, debugging many times, When deploying, javac, copy, jar,
java that would be hard work. Now see how ant does them gracefully.
To run ant, you need to have a build.xml. Although it does not have to be called this name, it is recommended that you do so
. Below is a complete build.xml, and then we will explain each sentence in detail
<?xml version="1.0" encoding=" UTF-8" ?>
<project name="HelloWorld" default="run" basedir=".">
<property name="src" value="src"/>
<property name="dest" value="classes" />
<property name="hello_jar" value="hello1.jar"/>
<target name="init">
<mkdir dir="${dest}"/>
</target>
<target name="compile" depends ="init">
<javac srcdir="${src}" destdir="${dest}"/>
<
<java classname="test.ant.HelloWorld" classpath="${hello_jar}"/>
</target>
<target name="clean">
<delete dir="${dest}" />
<delete file="${hello_jar}" />
</target>
<target name="rerun" depends="clean,run">
<ant target="clean" />
<ant target="run" />
</target>
</project>
解释：
<?xml version="1.0" encoding="UTF-8" ?>
build.xml中的第一句话，没有实际的意义
<project name="HelloWorld" default="run" basedir=".">
</project>
ant的所有内容必须包含在这个里边，name是你给它取的名字，basedir故名思意就是工作的根目录 .代表当前目录。default代表默认要做的事情。
<property name="src" value="src"/>
类似程序中的变量，为什么这么做想一下变量的作用
<target name="compile" depends="init">
<javac srcdir="${src}" destdir="${dest}"/>
</target>Write
everything you want to do as a target, it has a name, depends is the target it depends on, Before executing this target, such as compile here, ant will first check whether init has been executed. If it has been executed, it
will directly execute compile. If not, it will first execute the target it depends on, such as init here, and then execute the target
such as Our plan to
compile:
<target name="compile" depends="init">
<javac srcdir="${src}" destdir="${dest}"/>
</target>
make a jar package:
<target name= "build" depends="compile">
<jar jarfile="${hello_jar}" basedir="${dest}"/>
</target>
run:
<target name="run" depends="build">
<java classname="test.ant.HelloWorld"classpath="${hello_jar}"/>
</target>
In order not to copy, we can define the target folder at the beginning, so that ant directly puts the result in the target folder.
New folder:
You will find that each task has been completed. Every time we change the code, we just need to type ant again . Sometimes we don't want to run the program, we just want to perform one or two of these steps. For example, I just want to redeploy and not run, type ant build ant each time in ant. A task can call ant + target name like this, such a simple ant task is completed.
1. When to use ant
. Maybe you hear others talking about ant, and you are ready to learn ant on a whim. When you read the first example above, you may feel that ant is really good, or you may feel that ant is nothing more than that. Come to these The conclusion can't be wrong. Although ant is very useful,
it is not the best choice in any situation. For example, there are more simpler and easier-to-use tools on windows, such as eclipse+myeclipse eclipse+wtp, etc. , whether it is compiling, deploying or running, it is
easier and more convenient to use than ant, but in some cases, it is a good place for ant to play:
1. When deploying on the
server When your program is developed and the deployer wants to deploy it on the server , you can't configure an eclipse+myeclipse just because you install a program, ant is a good choice at this time, because it is small and easy to
configure , you can bring the build.xml you wrote to any server. , wouldn't it be nice to make simple changes (some settings, such as directories), and then one or two commands to complete.
2. On linux, this is often the case. Program development is under windows, but the program needs to run on linux or
unix. It is a troublesome thing to deploy on linux or unix (especially on unix). The characteristics of ant at this time It came out again, because ant is cross-platform, you can use it on most operating systems in build.xml, basically no need to modify it.
3. When the server maintainers don't know programming.
Many people have had such experiences. People who use your programs don't know how to write programs. You have to re-deploy the program again and again because of version updates, because fixing bugs. At this time you will find that teaching a person is so difficult. But
after there is ant, you just need to tell him, enter one or two commands such as ant xxx, everything is ok.
The above are some of the situations I have encountered.
After reading the above situation, think about whether you need to use ant, and if so, continue.
Further learning of a slightly more complex ant
may occur in the actual work process. A project is divided into many modules, and each group or department is responsible for a module. For testing, they wrote a build.xml themselves, And you are responsible for combining these modules
together.
When you write a build.xml, you have two options:
1. Re-write a build.xml yourself, which will be a troublesome thing.
2. Try to use what they have already written. build.xml, reduce your own work
For example:
Suppose you have three teams under you, each team is responsible for a part, they have a src and a written build.xml
At this time, you get their src, you need What it does is to create three folders src1 , src2 , src3 and put their src and build.xml into them respectively, and then write a build.xml
<?xml version="1.0" encoding="UTF-8" ?>
<project name="main" default="build" basedir=".">
<property name="bin" value="${basedir}\bin" />
<property name="src1" value="${basedir}\ src1" />
<property name="src2" value="${basedir}\src2" />
<property name="src3" value="${basedir}\src3" />
<target name="init">
<mkdir dir="${bin}" />
</target>
<target name="run">
<ant dir="${src1}" target="run" />
<ant dir="${src2}" target="run" />
<ant dir="${src3}" target="run" />
</target>
<target name="clean">
<ant dir="${src1}" target="clean" />
<ant dir="${src2}" target="clean" />
<ant dir="${src3}" target="clean" />
</target>
<target name="build" depends="init,call">
<copy todir="${bin}">
<fileset dir="${src1}">
<include name="*.jar" />
</fileset>
<fileset dir="${src2}">
<include name="*.jar" />
</fileset>
<fileset dir="${src3}">
<include name="*.jar" />
</fileset>
</copy>
</target>
<target name="rebuild" depends="build,clean">
<ant target="clean" />
<ant target="build" />
</target>
</project>
ok你的任务完成了。
ok, you have completed the task above, but do you have any feelings? In those build.xml, most of them are repeated, and changing a directory needs to change a lot of things. Whether it can make the work a little better, the answer is yes.
Introduce two things:
1, property
2, xml include
These two things have a function, that is, they can separate the content in <propery /> in build.xml and use them together.
In addition, they have their own characteristics:
propery The feature of xml include is that it is easy to maintain and only needs simple key-value pairs, because not everyone likes the xml format
. The feature of xml include is that not only attributes can be extracted, but also targets.
Or the previous example:
for example, if we want to extract the three properties of src1, src2, and src3 from xml, we can create a new file called all.properties
with the contents
src1=D:\\study\\ant\\src1
src2=D: \\study\\ant\\src2
src3=D:\\study\\ant\\src3
Then your build.xml file can be written like this, others only need to change the configuration file, not your build.xml file
<?xml version="1.0" encoding="UTF-8" ?> <
project name="main" default="build" basedir=".">
<property file="all.
<property name="bin" value="${basedir}\bin" />
<target name="init">
<mkdir dir="${bin}" />
</target>
<target name="run">
<ant dir="${src1}" target="run" />
<ant dir="${src2}" target="run" />
<ant dir="${src3}" target="run" />
</target>
<target name="clean">
<ant dir="${src1}" target="clean" />
<ant dir="${src2}" target="clean" />
<ant dir="${src3}" target="clean" />
</target>
<target name="build" depends="init,call">
<copy todir="${bin}">
<fileset dir="${src1}">
<include name="*.jar" />
</fileset>
<fileset dir="${src2}">
<include name="*.jar" />
</fileset>
<fileset dir="${src3}">
<include name="*.jar" />
</fileset>
</copy>
</target>
<target name="rebuild" depends="build,clean">
<ant target="clean" />
<ant target="build" />
</target>
<target name="test">
<ant dir="${src1}" target="test" />
<ant dir="${src2}" target="test" />
<ant dir="${src3}" target="test" />
</target>
</project><ant dir="${src3}" target="test" /><ant dir="${src2}" target=" test" /><ant dir="${src1}" target="test" /><target name="test">
If you look at yourself you will see a target like this
</target>
Sometimes you want to add several targets to each team's build.xml. One way is to write them in each and call them here
. But there is a better way.
You can write an include.xml file with the following content
<?xml version="1.0" encoding="UTF-8" ?>
<property name="src" value="src"/>
<property name="dest" value ="classes"/>
<target name="test" >
<ant target="run" />
</target>
and then change the build.xml files of your three groups, each with the following contents
<!--include a xml file ,it can be common propery ,can be also a target -->
<!DOCTYPE project [
<!ENTITY share-variable SYSTEM "file:../include.xml">
]>
&share-variable;
becomes as follows This
time, you only need to include.
<?xml version="1.0" encoding="UTF-8" ?>
<!--include a xml file ,it can be common propery ,can be also a target -->
<!DOCTYPE project [
<!ENTITY share-variable SYSTEM "file:../include.xml">
]>
<project name="HelloWorld" default="run" basedir=".">
<!--use the include -->
&share-variable;
<!--defined the property-->
<!--via include
<property name="src" value="src"/>
<property name="dest" value="classes"/>
-->
<property name="hello_jar" value="hello1.jar"/>
<!--define the op-->
<target name="init">
<mkdir dir="${dest}"/>
</target>
<target name="compile" depends="init">
<javac srcdir="${src}" destdir="${dest}"/>
</target>
<target name="build" depends="compile">
<jar jarfile="${hello_jar}" basedir="${dest}"/>
</target>
<target name="run" depends="build">
<java classname="test.ant.HelloWorld" classpath="${hello_jar}"/>
</target>
<target name="clean">
<delete dir="${dest}" />
<delete file="${hello_jar}" />
</target>
<target name="rerun" depends="clean,run">
<ant target="clean" />
<ant target="run" />
</target>
</project>
After mastering the above content, you will know how to write a good ant, but you will find that when you really want to do it, you can't make a good build.xml right away, because you know too little ant The command provided by default. At this
time, if you want to complete the task and improve yourself, there are many ways:
1. Many open source programs have build.xml, look at how they are written
2, ant's document, which is detailed The various default commands of ant are listed, and their richness
3, google, never forget it is
ok, after this, as you write more and more ant builds, the more commands you know, ant is in your The hands are getting stronger.
This is a gradual accumulation process.
The example of ant is easy to find. Various open source frameworks will have a build.xml with a careful look, and there will be great gains.
Another one that is often used, but generally not available in the build.xml of open source frameworks is that
if cvs is used The remote cvs can be used like this
<xml version="1.0" encoding="utf-8"?>
<project>
<property name="cvsroot" value=":pserver:wang:@192.168.1.2:/cvsroot "/>
<property name="basedir" value="/tmp/testant/"/>
<property name="cvs.password" value="wang"/>
<property name="cvs.passfile" value="$ {basedir}/ant.cvspass"/>
<target name="initpass">
<cvspass cvsroot="${cvsroot}" password="${cvs.password}" passfile="${cvs.passfile}"/>
</target>
<target name="checkout" depends="initpass">
<cvs cvsroot="${cvsroot}" command="checkout" cvsrsh="ssh" package="myproject" dest="${basedir}"
passfile="${cvs.passfile}"/>
</target>
</project>
In eclipse, ant is innately supported, so you can write build.xml directly in eclipse.
Because eclipse provides prompt function and automatic supplement function, it can make you do more with less.
To use the method, you only need to create a project, and then create a file called build.xml. Then you can write your ant build in
it but always remember that http://www.apache.org/ will always find what you need
Source: http://www.cnblogs.com/wufengxyz/archive/2011/11/24/2261797.html